I'm pretty dumb when it comes to software licenses...

# mathematics

[Andrew]

I'm pretty dumb when it comes to software licenses. What are the implications of porting and heavily modifying something like BigInteger from the openJdk source to kotlin? Is that allowed? Do I just need to keep the license part, and does that apply to my entire project or just that class?

[altavir]

Openjdk is using gpl licence. It means you mast publish anything that uses it under gpl since it is viral. And you can't put a license on a single class, only a standalone jar. There are multiple multiplatform bigint implementations. The one in kmath seems to be even more effective than jdk. You can use it since it or copy the code since it is under Apache.

[Andrew]

Where in kmath is it? I didn't see anything

[altavir]

https://github.com/mipt-npm/kmath/blob/dev/kmath-core/src/commonMain/kotlin/kscience/kmath/operations/BigInt.kt nobody ever added big decimal on top of it, but prs are welcome

[Andrew]

Thanks, not sure how I missed that I looked in several other directories but not that one, will check it out. Going to try BigDecimal eventually but obviously need all this working first

[altavir]

There are several other implementations, but checks @Peter Klimai and the code authors run show that this one is the best so far. A contribution of BigDecimal part would be welcome.

[Andrew]

This was on my own code but do you have any idea how UIntArray is faster than IntArray? All I did was change to that and got 10% speed up. Internally its still an int and gets converted to Long for any basic operation so not sure what's different.

[altavir]

The performance changes of 10-20% are very hard to predict on jvm due to not and very hard to measure correctly (did you use JMH?). As it is, uintarray does not give anything but the safety.

[Andrew]

I will look into JMH, this is the first time I've cared to benchmark two things this closely. I consistently get 1-2% variation in times between test runs so anything more than that is noticeable and usually correlates with a code change (for better or worse)