Hi,
- The SRFI-70 states that R5RS's number specification is inconsistent for some cases, and describes a replacement for this section. - Gambit does extend some of the functionality from R5RS, like infinites, but mentions no SRFI-70. - An then, SRFI-70 is superseded by R6RS.
So where does Gambit stand in this space?
Best regards,
Álvaro
Afficher les réponses par date
Gambit's level of influence from R6RS is really low - there's some procedures Gambit would have had anyhow that follow the R6RS naming, something like this - so I suppose Gambit's numbers spec does not take R6RS in consideration.
What would the differences between the numbers spec of SRFI70 and R6RS be btw?
2012/12/25 Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com
Hi,
- The SRFI-70 states that R5RS's number specification is inconsistent for
some cases, and describes a replacement for this section.
- Gambit does extend some of the functionality from R5RS, like infinites,
but mentions no SRFI-70.
- An then, SRFI-70 is superseded by R6RS.
So where does Gambit stand in this space?
Best regards,
Álvaro
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Dec 25, 2012, at 9:49 AM, Álvaro Castro-Castilla wrote:
Hi,
- The SRFI-70 states that R5RS's number specification is inconsistent for some cases, and describes a replacement for this section.
- Gambit does extend some of the functionality from R5RS, like infinites, but mentions no SRFI-70.
- An then, SRFI-70 is superseded by R6RS.
So where does Gambit stand in this space?
Gambit does not consciously attempt to conform to R6RS, but if there are "inconsistencies" in Gambit's numbers implementation I'd be interested to hear about them and willing to fix them.
Brad
Well, I was asking, so I can't really tell :) But SRFI-70 is supposed to be specifically designed to "improve" on R5RS, whether we/I agree or not that it is an improvement. The point is that Gambit is extending R5RS, even implementing some of the funcionality that R6RS specified (like flonum/fixnum operations). To be honest, I really don't get the difference between inexact/flonum exact/fixnum in Gambit. Documentation is not very extense on this topic, as far as I can tell the same operations apply to inexact/flonum, ditto exact/fixnum. But I think that if you are going to produce numeric code in Gambit, understanding this topic well enough is key.
SRFI-70 "redefines" R5RS number section (6.2). It modifies these areas (quoted from the SRFI):
* incorporates an inexact real positive infinity and an inexact real negative infinity (Gambit implements this) * extends number syntax to incorporate inexact real infinities, (Gambit implements this) adapts Common-Lisp semantics for `expt' and extends them to include inexact real infinities, corrects the description of `sqrt', sharpens the distinction between exact and inexact numbers removes a contradiction related to exactness, extends `gcd' and `lcm' to exact rational numbers, extends `quotient', `modulo', and `remainder' to finite real numbers, clarifies the behavior of `inexact->exact' applied to an exact argument, clarifies the behavior of `exact->inexact' applied to an inexact argument, adds convenience procedures `exact-round', `exact-ceiling', `exact-floor', and `exact-truncate',
These topics, specially for numerical methods implementation, seem to me as topics to understand well. Now, I don's say SRFI-70 proposal is better than R5RS, but I'd like to know what "standard" follows Gambit, to work under those premises.
Thank you very much,
Best regards
On Wed, Dec 26, 2012 at 5:06 PM, Bradley Lucier lucier@math.purdue.eduwrote:
On Dec 25, 2012, at 9:49 AM, Álvaro Castro-Castilla wrote:
Hi,
- The SRFI-70 states that R5RS's number specification is inconsistent
for some cases, and describes a replacement for this section.
- Gambit does extend some of the functionality from R5RS, like
infinites, but mentions no SRFI-70.
- An then, SRFI-70 is superseded by R6RS.
So where does Gambit stand in this space?
Gambit does not consciously attempt to conform to R6RS, but if there are "inconsistencies" in Gambit's numbers implementation I'd be interested to hear about them and willing to fix them.
Brad
Regarding Gambit's flonums and fixnums, besides R5RS, are these assertions right?:
- A flonum is a floating point number (double) - A fixnum is an integer (long) - An exact number is either a fixnum or a quotient numbers (a/b) - An inexact number is equal to a flonum
- fx operations apply to all exact numbers except quotient-like numbers. - All fl operations apply to flonums
In order to use an exact number that happens to be a quotient with fl operations you need to apply ROUND, FLOOR or CEILING.
Am I missing something out?
On Wed, Dec 26, 2012 at 6:53 PM, Álvaro Castro-Castilla < alvaro.castro.castilla@gmail.com> wrote:
Well, I was asking, so I can't really tell :) But SRFI-70 is supposed to be specifically designed to "improve" on R5RS, whether we/I agree or not that it is an improvement. The point is that Gambit is extending R5RS, even implementing some of the funcionality that R6RS specified (like flonum/fixnum operations). To be honest, I really don't get the difference between inexact/flonum exact/fixnum in Gambit. Documentation is not very extense on this topic, as far as I can tell the same operations apply to inexact/flonum, ditto exact/fixnum. But I think that if you are going to produce numeric code in Gambit, understanding this topic well enough is key.
SRFI-70 "redefines" R5RS number section (6.2). It modifies these areas (quoted from the SRFI):
- incorporates an inexact real positive infinity and an inexact real
negative infinity (Gambit implements this)
- extends number syntax to incorporate inexact real infinities, (Gambit
implements this) adapts Common-Lisp semantics for `expt' and extends them to include inexact real infinities, corrects the description of `sqrt', sharpens the distinction between exact and inexact numbers removes a contradiction related to exactness, extends `gcd' and `lcm' to exact rational numbers, extends `quotient', `modulo', and `remainder' to finite real numbers, clarifies the behavior of `inexact->exact' applied to an exact argument, clarifies the behavior of `exact->inexact' applied to an inexact argument, adds convenience procedures `exact-round', `exact-ceiling', `exact-floor', and `exact-truncate',
These topics, specially for numerical methods implementation, seem to me as topics to understand well. Now, I don's say SRFI-70 proposal is better than R5RS, but I'd like to know what "standard" follows Gambit, to work under those premises.
Thank you very much,
Best regards
On Wed, Dec 26, 2012 at 5:06 PM, Bradley Lucier lucier@math.purdue.eduwrote:
On Dec 25, 2012, at 9:49 AM, Álvaro Castro-Castilla wrote:
Hi,
- The SRFI-70 states that R5RS's number specification is inconsistent
for some cases, and describes a replacement for this section.
- Gambit does extend some of the functionality from R5RS, like
infinites, but mentions no SRFI-70.
- An then, SRFI-70 is superseded by R6RS.
So where does Gambit stand in this space?
Gambit does not consciously attempt to conform to R6RS, but if there are "inconsistencies" in Gambit's numbers implementation I'd be interested to hear about them and willing to fix them.
Brad
I don't know what internal model you have of Gambit's numbers, but here's a block comment in _num#.scm that explains some of the relationships between Gambit's number representations.
;;;============================================================================ ;;; Number representation. ;; There are 5 internal representations for numbers: ;; ;; fixnum, bignum, ratnum, flonum, cpxnum ;; ;; Fixnums and bignums form the class of exact-int. ;; Fixnums, bignums and ratnums form the class of exact-real. ;; Fixnums, bignums, ratnums and flonums form the class of noncpxnum. ;; The representation has some invariants: ;; ;; The numerator of a ratnum is a non-zero exact-int. ;; The denominator of a ratnum is an exact-int greater than 1. ;; The numerator and denominator have no common divisors greater than 1. ;; ;; The real part of a cpxnum is a noncpxnum. ;; The imaginary part of a cpxnum is a noncpxnum != fixnum 0 ;; The following table gives the mapping of the Scheme exact numbers to their ;; internal representation: ;; ;; type representation ;; exact integer = exact-int (fixnum, bignum) ;; exact rational = exact-real (fixnum, bignum, ratnum) ;; exact real = exact-real (fixnum, bignum, ratnum) ;; exact complex = exact-real or cpxnum with exact-real real and imag parts ;; For inexact numbers, the representation is not quite as straightforward. ;; ;; There are 3 special classes of inexact representation: ;; flonum-int : flonum with integer value ;; cpxnum-real: cpxnum with imag part = flonum 0.0 or -0.0 ;; cpxnum-int : cpxnum-real with exact-int or flonum-int real part ;; ;; Note: cpxnum-real and cpxnum-int only exist if ;; (macro-cpxnum-are-possibly-real?) returns #t. ;; ;; This gives the following table for Scheme's inexact numbers: ;; ;; type representation ;; inexact integer = flonum-int or cpxnum-int if it exists ;; inexact rational = flonum or cpxnum-real if it exists ;; inexact real = flonum or cpxnum-real if it exists ;; inexact complex = flonum or cpxnum with flonum real or imag part
The maximum and minimum fixnums can be queried; for example, in a 64-bit implementation:
##max-fixnum
2305843009213693951
##min-fixnum
-2305843009213693952
Exact integers outside this range are bignums. Bignums are limited in size based on how big an individual object can be in Gambit (about (expt 2 24) bytes in a 32-bit implementation and (expt 2 56) bytes (i.e., basically unlimited) in a 64-bit implementation).
Inexact numbers are the same as C doubles (64-bit). Extended precision floating-point numbers (80-bit numbers) are used in extremis on machines that do not support 64-bit floating-point numbers natively. (Don't ask.)
fx operations expect fixnum operands and yield fixnum results, fl operations expect flonum operands and yield flonum results. Code compiled with "safe" declarations (the default) check these assumptions and throw an error if they fail; code compiled with "not safe" declarations do not make these checks and can yield incorrect results or crash the program if these assumptions are violated.
Brad
Thank you.
Actually, I've just watched Marc's video about the 90-mins scheme to C compiler and I feel more ready to at least open gambit's implementation files. Is something I feared doing, but I see that is fundamental to understand this sort of stuff.
Your explanation clarifies a couple of misconceptions I had on fixnums.
Best regards,
Álvaro
On Fri, Dec 28, 2012 at 5:53 PM, Bradley Lucier lucier@math.purdue.eduwrote:
I don't know what internal model you have of Gambit's numbers, but here's a block comment in _num#.scm that explains some of the relationships between Gambit's number representations.
;;;============================================================================ ;;; Number representation. ;; There are 5 internal representations for numbers: ;; ;; fixnum, bignum, ratnum, flonum, cpxnum ;; ;; Fixnums and bignums form the class of exact-int. ;; Fixnums, bignums and ratnums form the class of exact-real. ;; Fixnums, bignums, ratnums and flonums form the class of noncpxnum. ;; The representation has some invariants: ;; ;; The numerator of a ratnum is a non-zero exact-int. ;; The denominator of a ratnum is an exact-int greater than 1. ;; The numerator and denominator have no common divisors greater than 1. ;; ;; The real part of a cpxnum is a noncpxnum. ;; The imaginary part of a cpxnum is a noncpxnum != fixnum 0 ;; The following table gives the mapping of the Scheme exact numbers to their ;; internal representation: ;; ;; type representation ;; exact integer = exact-int (fixnum, bignum) ;; exact rational = exact-real (fixnum, bignum, ratnum) ;; exact real = exact-real (fixnum, bignum, ratnum) ;; exact complex = exact-real or cpxnum with exact-real real and imag parts ;; For inexact numbers, the representation is not quite as straightforward. ;; ;; There are 3 special classes of inexact representation: ;; flonum-int : flonum with integer value ;; cpxnum-real: cpxnum with imag part = flonum 0.0 or -0.0 ;; cpxnum-int : cpxnum-real with exact-int or flonum-int real part ;; ;; Note: cpxnum-real and cpxnum-int only exist if ;; (macro-cpxnum-are-possibly-real?) returns #t. ;; ;; This gives the following table for Scheme's inexact numbers: ;; ;; type representation ;; inexact integer = flonum-int or cpxnum-int if it exists ;; inexact rational = flonum or cpxnum-real if it exists ;; inexact real = flonum or cpxnum-real if it exists ;; inexact complex = flonum or cpxnum with flonum real or imag part
The maximum and minimum fixnums can be queried; for example, in a 64-bit implementation:
##max-fixnum
2305843009213693951
##min-fixnum
-2305843009213693952
Exact integers outside this range are bignums. Bignums are limited in size based on how big an individual object can be in Gambit (about (expt 2 24) bytes in a 32-bit implementation and (expt 2 56) bytes (i.e., basically unlimited) in a 64-bit implementation).
Inexact numbers are the same as C doubles (64-bit). Extended precision floating-point numbers (80-bit numbers) are used in extremis on machines that do not support 64-bit floating-point numbers natively. (Don't ask.)
fx operations expect fixnum operands and yield fixnum results, fl operations expect flonum operands and yield flonum results. Code compiled with "safe" declarations (the default) check these assumptions and throw an error if they fail; code compiled with "not safe" declarations do not make these checks and can yield incorrect results or crash the program if these assumptions are violated.
Brad
On 28 December 2012 16:53, Bradley Lucier lucier@math.purdue.edu wrote:
Inexact numbers are the same as C doubles (64-bit). Extended precision floating-point numbers (80-bit numbers) are used in extremis on machines that do not support 64-bit floating-point numbers natively. (Don't ask.)
Too late. Besides i have a penchant for quirky/bizarre architectures. Are we talking about x86 here? There are so many bizarro combinations in that processor family...
david
On Dec 29, 2012, at 10:04 PM, David Rush wrote:
On 28 December 2012 16:53, Bradley Lucier lucier@math.purdue.edu wrote: Inexact numbers are the same as C doubles (64-bit). Extended precision floating-point numbers (80-bit numbers) are used in extremis on machines that do not support 64-bit floating-point numbers natively. (Don't ask.)
Too late. Besides i have a penchant for quirky/bizarre architectures. Are we talking about x86 here?
x86 without the SSE extension. In which case the precision of the mantissa of operations is set to 53 bits, but the exponent range of operations is still the exponent range of extended reals. But inexact numbers are still stored as doubles.
I don't remember all the details; most of the time, results are as expected, but not always---for subnormal numbers double rounding can sometimes occur, for example.
Brad