BigInt implementation #81
@ -0,0 +1,398 @@
|
|||||||
|
|||||||
|
package scientifik.kmath.operations
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
import kotlin.math.max
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
import kotlin.math.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)
|
|||||||
|
* Kotlin Multiplatform implementation of Big Integer numbers (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)
|
|||||||
|
* Initial version from https://github.com/robdrynkin/kotlin-big-integer
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
typealias Magnitude = UIntArray
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
typealias TBase = ULong
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
object KBigIntegerRing: Ring<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)
|
|||||||
|
override val zero: KBigInteger = 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)
|
|||||||
|
override val one: KBigInteger = KBigInteger.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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 add(a: KBigInteger, b: KBigInteger): KBigInteger = a.plus(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)
|
|||||||
|
override fun multiply(a: KBigInteger, k: Number): KBigInteger = a.times(k.toLong())
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 multiply(a: KBigInteger, b: KBigInteger): KBigInteger = a.times(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)
|
|||||||
|
operator fun String.unaryPlus(): KBigInteger = KBigInteger(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)
|
|||||||
|
operator fun String.unaryMinus(): KBigInteger = -KBigInteger(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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
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?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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: Int) : this(x.sign, 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)
|
|||||||
|
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)
|
|||||||
|
(kotlin.math.abs(x).toULong() 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)
|
|||||||
|
((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)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 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)
|
|||||||
|
const val BASE_SIZE: Int = 32
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 ZERO: 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)
|
|||||||
|
val ONE: KBigInteger = 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)
|
|||||||
|
private val hexMapping: HashMap<UInt, 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)
|
|||||||
|
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)
|
|||||||
|
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",
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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"
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 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)
|
|||||||
|
// TODO: optimize performance
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 resSize: Int = mag.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)
|
|||||||
|
while (mag[resSize] == 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)
|
|||||||
|
if (resSize == 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)
|
|||||||
|
break
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
resSize -= 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)
|
|||||||
|
return mag.sliceArray(IntRange(0, 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 compareMagnitudes(mag1: Magnitude, mag2: Magnitude): 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)
|
|||||||
|
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)
|
|||||||
|
mag1.size > mag2.size -> return 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)
|
|||||||
|
mag1.size < mag2.size -> return -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 -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag1.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)
|
|||||||
|
if (mag1[i] > mag2[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)
|
|||||||
|
return 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 if (mag1[i] < mag2[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)
|
|||||||
|
return -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)
|
|||||||
|
return 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 addMagnitudes(mag1: Magnitude, mag2: 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)
|
|||||||
|
val resultLength: Int = max(mag1.size, mag2.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 result = Magnitude(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 carry: TBase = 0UL
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 0 until resultLength - 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 res = 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)
|
|||||||
|
i >= mag1.size -> mag2[i].toULong() + carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
i >= mag2.size -> mag1[i].toULong() + carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 -> mag1[i].toULong() + mag2[i].toULong() + carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
result[i] = (res 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)
|
|||||||
|
carry = (res shr 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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.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)
|
|||||||
|
return 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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 resultLength: Int = mag1.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 result = Magnitude(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 carry = 0L
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 0 until resultLength) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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: Long =
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 < mag2.size) mag1[i].toLong() - mag2[i].toLong() - carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag1[i].toLong() - carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
carry = if (res < 0) 1 else 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)
|
|||||||
|
res += carry * (BASE + 1UL).toLong()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
result[i] = res.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)
|
|||||||
|
return 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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 resultLength: Int = mag.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 result = Magnitude(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 carry: ULong = 0UL
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag.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)
|
|||||||
|
val cur: ULong = carry + mag[i].toULong() * x.toULong()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 and BASE.toULong()).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)
|
|||||||
|
carry = cur shr 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 resultLength: Int = mag1.size + mag2.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 result = Magnitude(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag1.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)
|
|||||||
|
var carry: ULong = 0UL
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag2.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)
|
|||||||
|
val cur: ULong = result[i + j].toULong() + mag1[i].toULong() * mag2[j].toULong() + carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 + j] = (cur and BASE.toULong()).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)
|
|||||||
|
carry = cur shr 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
internal fun divideMagnitudeByUInt(mag: Magnitude, x: UInt): 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)
|
|||||||
|
val resultLength: Int = mag.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 result = Magnitude(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 carry: ULong = 0UL
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag.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)
|
|||||||
|
val cur: ULong = mag[i].toULong() + (carry shl 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)
|
|||||||
|
result[i] = (cur / 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)
|
|||||||
|
carry = cur % x
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
internal fun divideMagnitudes(mag1_: Magnitude, mag2: 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)
|
|||||||
|
val mag1 = ULongArray(mag1_.size) { mag1_[it].toULong() }
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 resultLength: Int = mag1.size - mag2.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 result = LongArray(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag1.size - 1 downTo mag2.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 div: ULong = mag1[i] / mag2[mag2.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)
|
|||||||
|
result[i - mag2.size + 1] = div.toLong()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 mag2.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)
|
|||||||
|
mag1[i - j] -= mag2[mag2.size - 1 - j] * div
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 > 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)
|
|||||||
|
mag1[i - 1] += (mag1[i] shl 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 normalizedResult = Magnitude(resultLength)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 carry = 0L
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 result.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)
|
|||||||
|
result[i] += carry
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (result[i] < 0L) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
normalizedResult[i] = (result[i] + (BASE + 1UL).toLong()).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)
|
|||||||
|
carry = -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 {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
normalizedResult[i] = result[i].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)
|
|||||||
|
carry = 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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 normalizedResult
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 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)
|
|||||||
|
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 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 < other -> 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 == other -> 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)
|
|||||||
|
else -> KBigInteger(this.sign * other.sign, divideMagnitudes(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)
|
|||||||
|
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)
|
|||||||
|
}
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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(x: 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 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)
|
|||||||
|
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
// Can't put it as constructor in class due to platform declaration clash with 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)
|
|||||||
|
fun KBigInteger(x: 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)
|
|||||||
|
= KBigInteger(1, uintArrayOf(x))
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
// Can't put it as constructor in class due to platform declaration clash with KBigInteger(Long)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 KBigInteger(x: ULong): 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)
|
|||||||
|
= KBigInteger(1, uintArrayOf((x and KBigInteger.BASE).toUInt(), ((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)
|
|||||||
|
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,
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 KBigInteger(s: String): 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)
|
|||||||
|
val sign: 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 sPositive: 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)
|
|||||||
|
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)
|
|||||||
|
s[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)
|
|||||||
|
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)
|
|||||||
|
sPositive = s.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] == '-' -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
sPositive = s.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 -> {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
sPositive = s
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
var res = 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 digitValue = KBigInteger.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)
|
|||||||
|
val sPositiveUpper = sPositive.toUpperCase()
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (sPositiveUpper.startsWith("0X")) { // hex representation
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 sHex = sPositiveUpper.substring(2)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (ch in sHex.reversed()) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (ch == '_') continue
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 += digitValue * (hexChToInt[ch] ?: return null)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html)
|
|||||||
|
digitValue *= KBigInteger(16)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
else { // decimal representation
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 sDecimal = sPositiveUpper
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (ch in sDecimal.reversed()) {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (ch == '_') continue
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 (ch !in '0'..'9') {
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 null
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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)
|
|||||||
|
res += digitValue * (ch.toInt() - '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)
|
|||||||
|
digitValue *= KBigInteger(10)
|
||||||
Why use whole Why use whole `Int` for simple three way flag? Could it be replaced by boolean? Enum?
Move to private constructor and move parameter checks to auxiliary builders. Move to private constructor and move parameter checks to auxiliary builders.
Companion should be last declaration in the class Companion should be last declaration in the class
Also all internal values must be marked as private Also all internal values must be marked as private
should be virtual if it is not performance-critical should be virtual if it is not performance-critical
It does not make sense to make it RingElement since all operations are already class members. It does not make sense to make it RingElement since all operations are already class members.
Refactor to String.toBigInteger() Refactor to String.toBigInteger()
Now using Byte for that Now using Byte for that
Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement? Even byte is wasteful. Especially considering that my eat whole word due to alignment. Why not use 2-complement?
This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of different length. At least the classical Java BigInt implementation stores magnitude and signum separately (http://developer.classpath.org/doc/java/math/BigInteger-source.html) This may be a good idea, but I suspect (performance) problems with 2-complement will appear when we try to operate with numbers of 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 * 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)
|
@ -0,0 +1,480 @@
|
|||||||
|
package scientifik.kmath.operations
|
||||||
|
|
||||||
|
import kotlin.test.Test
|
||||||
|
import kotlin.test.assertTrue
|
||||||
|
import kotlin.test.assertEquals
|
||||||
|
|
||||||
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
|
class KBigIntegerConstructorTest {
|
||||||
|
@Test
|
||||||
|
fun testConstructorZero() {
|
||||||
|
assertEquals(KBigInteger(0), KBigInteger(0, uintArrayOf()))
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testConstructor8() {
|
||||||
|
assertEquals(KBigInteger(8), KBigInteger(1, uintArrayOf(8U)))
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testConstructor_0xffffffffaL() {
|
||||||
|
val x = KBigInteger(-0xffffffffaL)
|
||||||
|
val y = KBigInteger(-1, uintArrayOf(0xfffffffaU, 0xfU))
|
||||||
|
assertEquals(x, y)
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
|
class KBigIntegerCompareTest {
|
||||||
|
@Test
|
||||||
|
fun testCompare1_2() {
|
||||||
|
val x = KBigInteger(1)
|
||||||
|
val y = KBigInteger(2)
|
||||||
|
assertTrue { x < y }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompare0_0() {
|
||||||
|
val x = KBigInteger(0)
|
||||||
|
val y = KBigInteger(0)
|
||||||
|
assertEquals(x, y)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompare1__2() {
|
||||||
|
val x = KBigInteger(1)
|
||||||
|
val y = KBigInteger(-2)
|
||||||
|
assertTrue { x > y }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompare_1__2() {
|
||||||
|
val x = KBigInteger(-1)
|
||||||
|
val y = KBigInteger(-2)
|
||||||
|
assertTrue { x > y }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompare_2__1() {
|
||||||
|
val x = KBigInteger(-2)
|
||||||
|
val y = KBigInteger(-1)
|
||||||
|
assertTrue { x < y }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompare12345_12345() {
|
||||||
|
val x = KBigInteger(12345)
|
||||||
|
val y = KBigInteger(12345)
|
||||||
|
assertEquals(x, y)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testEqualsWithLong() {
|
||||||
|
val x = KBigInteger(12345)
|
||||||
|
assertTrue { x == KBigInteger(12345L) }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testEqualsWithULong() {
|
||||||
|
val x = KBigInteger(12345)
|
||||||
|
assertTrue { x == KBigInteger(12345UL) }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompareBigNumbersGreater() {
|
||||||
|
val x = KBigInteger(0xfffffffffL)
|
||||||
|
val y = KBigInteger(0xffffffffaL)
|
||||||
|
assertTrue { x > y }
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompareBigNumbersEqual() {
|
||||||
|
val x = KBigInteger(0xffffffffaL)
|
||||||
|
val y = KBigInteger(0xffffffffaL)
|
||||||
|
assertEquals(x, y)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testCompareBigNumbersLess() {
|
||||||
|
val x = KBigInteger(-0xffffffffaL)
|
||||||
|
val y = KBigInteger(0xffffffffaL)
|
||||||
|
assertTrue { x < y }
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
|
class KBigIntegerOperationsTest {
|
||||||
|
@Test
|
||||||
|
fun testPlus_1_1() {
|
||||||
|
val x = KBigInteger(1)
|
||||||
|
val y = KBigInteger(1)
|
||||||
|
|
||||||
|
val res = x + y
|
||||||
|
val sum = KBigInteger(2)
|
||||||
|
|
||||||
|
assertEquals(sum, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testPlusBigNumbers() {
|
||||||
|
val x = KBigInteger(0x7fffffff)
|
||||||
|
val y = KBigInteger(0x7fffffff)
|
||||||
|
val z = KBigInteger(0x7fffffff)
|
||||||
|
|
||||||
|
val res = x + y + z
|
||||||
|
val sum = KBigInteger(1, uintArrayOf(0x7ffffffdU, 0x1U))
|
||||||
|
|
||||||
|
assertEquals(sum, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testUnaryMinus() {
|
||||||
|
val x = KBigInteger(1234)
|
||||||
|
val y = KBigInteger(-1234)
|
||||||
|
assertEquals(-x, y)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMinus_2_1() {
|
||||||
|
val x = KBigInteger(2)
|
||||||
|
val y = KBigInteger(1)
|
||||||
|
|
||||||
|
val res = x - y
|
||||||
|
val sum = KBigInteger(1)
|
||||||
|
|
||||||
|
assertEquals(sum, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMinus__2_1() {
|
||||||
|
val x = KBigInteger(-2)
|
||||||
|
val y = KBigInteger(1)
|
||||||
|
|
||||||
|
val res = x - y
|
||||||
|
val sum = KBigInteger(-3)
|
||||||
|
|
||||||
|
assertEquals(sum, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMinus___2_1() {
|
||||||
|
val x = KBigInteger(-2)
|
||||||
|
val y = KBigInteger(1)
|
||||||
|
|
||||||
|
val res = -x - y
|
||||||
|
val sum = KBigInteger(1)
|
||||||
|
|
||||||
|
assertEquals(sum, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMinusBigNumbers() {
|
||||||
|
val x = KBigInteger(12345)
|
||||||
|
val y = KBigInteger(0xffffffffaL)
|
||||||
|
|
||||||
|
val res = x - y
|
||||||
|
val sum = KBigInteger(-0xfffffcfc1L)
|
||||||
|
|
||||||
|
assertEquals(sum, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMultiply_2_3() {
|
||||||
|
val x = KBigInteger(2)
|
||||||
|
val y = KBigInteger(3)
|
||||||
|
|
||||||
|
val res = x * y
|
||||||
|
val prod = KBigInteger(6)
|
||||||
|
|
||||||
|
assertEquals(prod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMultiply__2_3() {
|
||||||
|
val x = KBigInteger(-2)
|
||||||
|
val y = KBigInteger(3)
|
||||||
|
|
||||||
|
val res = x * y
|
||||||
|
val prod = KBigInteger(-6)
|
||||||
|
|
||||||
|
assertEquals(prod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMultiply_0xfff123_0xfff456() {
|
||||||
|
val x = KBigInteger(0xfff123)
|
||||||
|
val y = KBigInteger(0xfff456)
|
||||||
|
|
||||||
|
val res = x * y
|
||||||
|
val prod = KBigInteger(0xffe579ad5dc2L)
|
||||||
|
|
||||||
|
assertEquals(prod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMultiplyUInt_0xfff123_0xfff456() {
|
||||||
|
val x = KBigInteger(0xfff123)
|
||||||
|
val y = 0xfff456U
|
||||||
|
|
||||||
|
val res = x * y
|
||||||
|
val prod = KBigInteger(0xffe579ad5dc2L)
|
||||||
|
|
||||||
|
assertEquals(prod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMultiplyInt_0xfff123__0xfff456() {
|
||||||
|
val x = KBigInteger(0xfff123)
|
||||||
|
val y = -0xfff456
|
||||||
|
|
||||||
|
val res = x * y
|
||||||
|
val prod = KBigInteger(-0xffe579ad5dc2L)
|
||||||
|
|
||||||
|
assertEquals(prod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMultiply_0xffffffff_0xffffffff() {
|
||||||
|
val x = KBigInteger(0xffffffffL)
|
||||||
|
val y = KBigInteger(0xffffffffL)
|
||||||
|
|
||||||
|
val res = x * y
|
||||||
|
val prod = KBigInteger(0xfffffffe00000001UL)
|
||||||
|
|
||||||
|
assertEquals(prod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun test_square_0x11223344U_0xad2ffffdU_0x17eU() {
|
||||||
|
val num = KBigInteger(-1, uintArrayOf(0x11223344U, 0xad2ffffdU, 0x17eU ))
|
||||||
|
println(num)
|
||||||
|
val res = num * num
|
||||||
|
assertEquals(res, KBigInteger(1, uintArrayOf(0xb0542a10U, 0xbbd85bc8U, 0x2a1fa515U, 0x5069e03bU, 0x23c09U)))
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testDivision_6_3() {
|
||||||
|
val x = KBigInteger(6)
|
||||||
|
val y = 3U
|
||||||
|
|
||||||
|
val res = x / y
|
||||||
|
val div = KBigInteger(2)
|
||||||
|
|
||||||
|
assertEquals(div, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testBigDivision_6_3() {
|
||||||
|
val x = KBigInteger(6)
|
||||||
|
val y = KBigInteger(3)
|
||||||
|
|
||||||
|
val res = x / y
|
||||||
|
val div = KBigInteger(2)
|
||||||
|
|
||||||
|
assertEquals(div, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testDivision_20__3() {
|
||||||
|
val x = KBigInteger(20)
|
||||||
|
val y = -3
|
||||||
|
|
||||||
|
val res = x / y
|
||||||
|
val div = KBigInteger(-6)
|
||||||
|
|
||||||
|
assertEquals(div, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testBigDivision_20__3() {
|
||||||
|
val x = KBigInteger(20)
|
||||||
|
val y = KBigInteger(-3)
|
||||||
|
|
||||||
|
val res = x / y
|
||||||
|
val div = KBigInteger(-6)
|
||||||
|
|
||||||
|
assertEquals(div, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testDivision_0xfffffffe00000001_0xffffffff() {
|
||||||
|
val x = KBigInteger(0xfffffffe00000001UL)
|
||||||
|
val y = 0xffffffffU
|
||||||
|
|
||||||
|
val res = x / y
|
||||||
|
val div = KBigInteger(0xffffffffL)
|
||||||
|
|
||||||
|
assertEquals(div, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testBigDivision_0xfffffffe00000001_0xffffffff() {
|
||||||
|
val x = KBigInteger(0xfffffffe00000001UL)
|
||||||
|
val y = KBigInteger(0xffffffffU)
|
||||||
|
|
||||||
|
val res = x / y
|
||||||
|
val div = KBigInteger(0xffffffffL)
|
||||||
|
|
||||||
|
assertEquals(div, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMod_20_3() {
|
||||||
|
val x = KBigInteger(20)
|
||||||
|
val y = 3
|
||||||
|
|
||||||
|
val res = x % y
|
||||||
|
val mod = 2
|
||||||
|
|
||||||
|
assertEquals(mod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testBigMod_20_3() {
|
||||||
|
val x = KBigInteger(20)
|
||||||
|
val y = KBigInteger(3)
|
||||||
|
|
||||||
|
val res = x % y
|
||||||
|
val mod = KBigInteger(2)
|
||||||
|
|
||||||
|
assertEquals(mod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testMod_0xfffffffe00000001_12345() {
|
||||||
|
val x = KBigInteger(0xfffffffe00000001UL)
|
||||||
|
val y = 12345
|
||||||
|
|
||||||
|
val res = x % y
|
||||||
|
val mod = 1980
|
||||||
|
|
||||||
|
assertEquals(mod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testBigMod_0xfffffffe00000001_12345() {
|
||||||
|
val x = KBigInteger(0xfffffffe00000001UL)
|
||||||
|
val y = KBigInteger(12345)
|
||||||
|
|
||||||
|
val res = x % y
|
||||||
|
val mod = KBigInteger(1980)
|
||||||
|
|
||||||
|
assertEquals(mod, res)
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testModPow_3_10_17() {
|
||||||
|
val x = KBigInteger(3)
|
||||||
|
val exp = KBigInteger(10)
|
||||||
|
val mod = KBigInteger(17)
|
||||||
|
|
||||||
|
val res = KBigInteger(8)
|
||||||
|
|
||||||
|
return assertEquals(res, x.modPow(exp, mod))
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testModPowBigNumbers() {
|
||||||
|
val x = KBigInteger(0xfffffffeabcdef01UL)
|
||||||
|
val exp = KBigInteger(2)
|
||||||
|
val mod = KBigInteger(0xfffffffeabcUL)
|
||||||
|
|
||||||
|
val res = KBigInteger(0x6deec7895faUL)
|
||||||
|
|
||||||
|
return assertEquals(res, x.modPow(exp, mod))
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testModBigNumbers() {
|
||||||
|
val x = KBigInteger(0xfffffffeabcdef01UL)
|
||||||
|
val mod = KBigInteger(0xfffffffeabcUL)
|
||||||
|
|
||||||
|
val res = KBigInteger(0xdef01)
|
||||||
|
|
||||||
|
return assertEquals(res, x % mod)
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
|
class KBigIntegerConversionsTest {
|
||||||
|
@Test
|
||||||
|
fun testToString0x10() {
|
||||||
|
val x = KBigInteger(0x10)
|
||||||
|
assertEquals("0x10", x.toString())
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testToString0x17ffffffd() {
|
||||||
|
val x = KBigInteger(0x17ffffffdL)
|
||||||
|
assertEquals("0x17ffffffd", x.toString())
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testToString_0x17ead2ffffd() {
|
||||||
|
val x = KBigInteger(-0x17ead2ffffdL)
|
||||||
|
assertEquals("-0x17ead2ffffd", x.toString())
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testToString_0x17ead2ffffd11223344() {
|
||||||
|
val x = KBigInteger(-1, uintArrayOf(0x11223344U, 0xad2ffffdU, 0x17eU ))
|
||||||
|
assertEquals("-0x17ead2ffffd11223344", x.toString())
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testFromString_0x17ead2ffffd11223344() {
|
||||||
|
val x = KBigInteger("0x17ead2ffffd11223344")!!
|
||||||
|
assertEquals( "0x17ead2ffffd11223344", x.toString())
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun testFromString_7059135710711894913860() {
|
||||||
|
val x = KBigInteger("-7059135710711894913860")
|
||||||
|
assertEquals("-0x17ead2ffffd11223344", x.toString())
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
@kotlin.ExperimentalUnsignedTypes
|
||||||
|
class DivisionTests {
|
||||||
|
// TODO
|
||||||
|
@Test
|
||||||
|
fun test_0xfffffffeabcdef01UL_0xfffffffeabc() {
|
||||||
|
val res = KBigInteger(0xfffffffeabcdef01UL) / KBigInteger(0xfffffffeabc)
|
||||||
|
assertEquals(res, KBigInteger(0x100000))
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
// println(KBigInteger(+1, uintArrayOf(1000U, 1000U, 1000U)) / KBigInteger(0xfffffffeabc) )
|
||||||
|
// >>> hex((1000 + 1000*2**32 + 1000*2**64)/ 0xfffffffeabc) == 0x3e800000L
|
||||||
|
// println(KBigInteger(+1, KBigInteger.divideMagnitudeByUInt(uintArrayOf(1000U, 1000U, 1000U),456789U)))
|
||||||
|
// 0x8f789719813969L
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
class KBigIntegerRingTest {
|
||||||
|
@Test
|
||||||
|
fun testSum() {
|
||||||
|
val res = KBigIntegerRing {
|
||||||
|
KBigInteger(1_000L) * KBigInteger(1_000L)
|
||||||
|
}
|
||||||
|
assertEquals(res, KBigInteger(1_000_000) )
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun test_sum_100_000_000__100_000_000() {
|
||||||
|
KBigIntegerRing {
|
||||||
|
val sum = +"100_000_000" + +"100_000_000"
|
||||||
|
assertEquals(sum, KBigInteger("200_000_000"))
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
@Test
|
||||||
|
fun test_mul_3__4() {
|
||||||
|
KBigIntegerRing {
|
||||||
|
val prod = +"0x3000_0000_0000" * +"0x4000_0000_0000_0000_0000"
|
||||||
|
assertEquals(prod, KBigInteger("0xc00_0000_0000_0000_0000_0000_0000_0000"))
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
}
|
||||||
|
|
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)