# [plt-scheme] number system

Sorry, the notion of inexact accepting a number-system-radix parameter
doesn't quite make sense as the inexactness comes from the machines inexact
value representation, therefore only an a conversion to exact implies a need
such a parameter defaulting to whatever number-system-radix is defined for
user interaction.
>* From: Paul Schlie <schlie at comcast.net>
*>* One of the suggestions which I really liked and thought it would help
*>* eliminate a lot of confusion, is the notion of you-see-what-you-get,
*>* with respect to the conversion between inexact and exact representations;
*>* as it would seem to be nice to expect something like:
*>*
*>>* (exact 0.3)
*>* 3/10
*>>* (inexact (exact 0.3))
*>* 0.3
*>>* (inexact 1/3)
*>* 0.33333333333
*>>* (exact (inexact 1/3))
*>* 33333333333/100000000000
*>*
*>* Where both exact and inexact could accept an optional number system radix
*>* parameter which defines the rounding mode of the conversion (defaulting to the
*>* environment setting), such that:
*>*
*>>* (exact (inexact 3/10 2) 2)
*>* 5404319552844595/18014398509481984
*>*
*>* As we get now, likely often creating confusion at times, as opposed to:
*>*
*>>* (exact (inexact 3/10))
*>* 3/10
*>*
*>* Which most would logically expect.
*>*
*>>* Zhu Chongkai wrote:
*>>* I just read the "Cleaning up the tower: Numbers in Scheme" from Scheme
*>>* WorkShop 2004. Although I do not agree with some of the points from the
*>>* paper, the current number system of Scheme implements is not so
*>>* satisfying. Will PLT scheme support arbitrary big real number (and
*>>* more)? Would it be a better solution to add a better number system into
*>>* SRFI?
*