spire
spire copied to clipboard
Powerful new number types and numeric abstractions for Scala.
## About this PR 📦 Updates * [org.typelevel:algebra](https://github.com/typelevel/cats) * [org.typelevel:algebra-laws](https://github.com/typelevel/cats) from `2.9.0` to `2.10.0` 📜 [GitHub Release Notes](https://github.com/typelevel/cats/releases/tag/v2.10.0) - [Version Diff](https://github.com/typelevel/cats/compare/v2.9.0...v2.10.0) ## Usage ✅ **Please merge!** I'll automatically update this...
Trying to estimate log(`BigDecimal`) starts infinite loop for some random `BigDecimal`s values, trying to test it and get this: ```scala timer.start() for(_
This is an umbrella issue for conversion of Spire types to/from strings. Currently, this is done in a quite adhoc way, which does not support composition well (as in `Complex[Rational]`...
Let's group here a bunch of stuff: #294 Support Eq in tests in a shouldEqv matcher (let's have a look) #601 BaseSyntaxTest uses .equals #599 No hashCode for Number #619...
UniqueFactorizationDomain tests are commented out for `BigInt` and `SafeLong`, we need to introduce a limit on size for those (and maybe other tests)
The toDouble method on Rational instances returns incorrectly for certain inputs. To reproduce, ```scala import spire.math.Rational def bld(numStr: String, denomStr: String): (Double, Double) = { val num = BigInt(numStr) val...
```scala import spire.algebra._, spire.implicits._ Field[BigDecimal].fromDouble(0).sqrt ``` throws: ``` java.lang.ArithmeticException: Cannot find the sqrt of a BigDecimal with unlimited precision. at spire.std.BigDecimalIsNRoot.sqrt(bigDecimal.scala:43) at spire.std.BigDecimalIsNRoot.sqrt$(bigDecimal.scala:41) at spire.std.BigDecimalAlgebra.sqrt(bigDecimal.scala:177) ... 36 elided ``` Affects...
There were proposals that could be revived now that we are modularizing Spire. #460 New spire.stats package @andrelfpinto 2015 #554 Spire.stats take 2 @andrelfpinto 2016
Is it a leftover of the past, when `Action[_, G]` had a `scalar: Semigroup[G]` instance ? Should we remove it (and its `Unbound` friends) ?
This is somewhat predicated on #226. If we had a faster big integer type, we could also build a better decimal type. One mistakes to avoid repeating: do not store...