You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scheme has the idea of a heirachical tower of numbers. Currently we only support double to represent Scheme's real numbers. This is standards-compliant but a bit underwhelming.
We should expand the numeric support to cover more of the tower:
comple represented by System.Numerics.Complex.
real represented by System.Double
integer represented by Sytem.Int64.
It might also be possible to support on-demand widening of integers from int to BigInteger. This leaves most of the numeric tower, appart from rationals, covered.
To support this we'd need to update the arithmetics library to allow calling with any of the number types. We'd need to address any places where numbers are unpacked as arguments and handle the different numeric types.
Given that the general representation here will be of boxed values it may be worth modelling this out as a class heirachy rather than just handling all supported numeric types at all call sites.
Some things to think about:
Boxed or class representation
Constant folding and numeric specialisations
How is this orthogonal tot he string / mutable string representation issue.
Scheme has the idea of a heirachical tower of numbers. Currently we only support
double
to represent Scheme's real numbers. This is standards-compliant but a bit underwhelming.We should expand the numeric support to cover more of the tower:
System.Numerics.Complex
.System.Double
Sytem.Int64
.It might also be possible to support on-demand widening of integers from
int
toBigInteger
. This leaves most of the numeric tower, appart from rationals, covered.To support this we'd need to update the arithmetics library to allow calling with any of the number types. We'd need to address any places where numbers are unpacked as arguments and handle the different numeric types.
Given that the general representation here will be of boxed values it may be worth modelling this out as a class heirachy rather than just handling all supported numeric types at all call sites.
Some things to think about:
string
/mutable string
representation issue.See also:
fixnums
: https://srfi.schemers.org/srfi-143/srfi-143.htmlflonums
: https://srfi.schemers.org/srfi-144/srfi-144.htmlThe text was updated successfully, but these errors were encountered: