Re: Improve "busy" numeric code's performance [was: Re: Big Integers]
With patch 0001 the elapsed time went from 33.7 seconds to 24.5 seconds. With patch 0002 the elapsed time went to 23.4 seconds. Good work -- Doug On Wednesday, May 22, 2024 at 08:54:49 AM MDT, Peter Bex wrote: On Wed, May 22, 2024 at 02:42:38PM +0200, Peter Bex wrote: > Attached are two patches, one which has this bigger improvement, and > another which is a minor improvement which translates to shaving about > a second of runtime off your program (at least on my machine). The minor patch was incorrect. I copied some code from C_s_a_i_remainder into C_s_a_i_modulo inline, but that code had an early return for the case where both numbers are flonums. This code needs to be adjusted to handle the case when the arguments aren't of the same sign, just like we do after returning from integer_divrem(). I'm sending both patches again for your convenience. The second patch has a fix for the aforementioned issue. Cheers, Peter
Re: Big Integers
Hello Mario, Yes, please add the program to the chicken-benchmarks. Regards,Doug On Wednesday, May 22, 2024 at 12:50:56 PM MDT, Mario Domenech Goulart wrote: Hi Doug, On Tue, 21 May 2024 21:35:33 + (UTC) "T.D. Telford" wrote: > Thanks for the reply. The elapsed timings for the program rho3rec are: > > chicken 5.3.0: 33.6 seconds > Racket v8.2 [cs] : 18.1 seconds > Dr Racket : 20.6 seconds (1 MB memory) > > The program uses the Pollard rho algorithm to find a factor of 2^257 -1. The > program is highly recursive, but I have a > non recursive version that has the same timing as the above. I am using an > AMD Ryzen 5600 cpu and 32 GB of main memory. > > I tried all of the csc options that appeared related to speed, and the > maximum improvement was 0.1 seconds. > > The one option I did not get to work was > -heap-size 1000M > where I varied the size from 1000M to 1M. In all cases I would get the > run time message > [panic] out of memory - heap full - execution terminated > > I have include the program listing below and also as an attachment. > > Regards, > Doug > > ;;; > ;;#lang racket ;; uncomment for racket > > (define (rho n u v c iter prod) > (let* ( [u1 (modulo (+ (* u u) c) n)] > [v1 (modulo (+ (* v v) c) n)] > [v2 (modulo (+ (* v1 v1) c) n)] > [done #f] > [max_iter 3000] > [iter2 (+ iter 1)] > [prod2 (modulo (* prod (- u1 v2)) n)] ) > > (if (= (modulo iter2 150) 0) > (begin ; modulo true > (let ( [g (gcd prod2 n) ] ) > (if (and (> g 1) (< g n)) > (begin ; factor > (display "factor = ") (display g) (newline) > (display "iterations = ") (display iter2) (newline) > (set! done #t) > ) > (set! prod2 1) ; no factor > ) ; end if factor > ) ; end let > ) ; end begin for modulo true > #f ;action for modulo false > ) ; end major if > > (if (and (< iter2 max_iter) (not done)) > (rho n u1 v2 c iter2 prod2) > (if done ; either found factor or max iterations > (display "normal termination \n") > #f > ) ; if done > ) ; if and > ) ; end let* > ) > > (let ( [n (- (expt 2 257) 1)] [u 2] [v 11] [c 7] [iter 1] [prod 1] ) > (display "factor n = ") (display n) (newline) > (time (rho n u v c iter prod)) > ) > > ;;; Thanks for providing the program. Would it be ok to add it as a benchmark program to https://github.com/mario-goulart/chicken-benchmarks? All the best. Mario -- http://parenteses.org/mario
Re: Big Integers
Hi Doug, On Tue, 21 May 2024 21:35:33 + (UTC) "T.D. Telford" wrote: > Thanks for the reply. The elapsed timings for the program rho3rec are: > > chicken 5.3.0: 33.6 seconds > Racket v8.2 [cs] : 18.1 seconds > Dr Racket : 20.6 seconds (1 MB memory) > > The program uses the Pollard rho algorithm to find a factor of 2^257 -1. The > program is highly recursive, but I have a > non recursive version that has the same timing as the above. I am using an > AMD Ryzen 5600 cpu and 32 GB of main memory. > > I tried all of the csc options that appeared related to speed, and the > maximum improvement was 0.1 seconds. > > The one option I did not get to work was > -heap-size 1000M > where I varied the size from 1000M to 1M. In all cases I would get the > run time message > [panic] out of memory - heap full - execution terminated > > I have include the program listing below and also as an attachment. > > Regards, > Doug > > ;;; > ;;#lang racket;; uncomment for racket > > (define (rho n u v c iter prod) > (let* ( [u1 (modulo (+ (* u u) c) n)] > [v1 (modulo (+ (* v v) c) n)] > [v2 (modulo (+ (* v1 v1) c) n)] > [done #f] > [max_iter 3000] > [iter2 (+ iter 1)] > [prod2 (modulo (* prod (- u1 v2)) n)] ) > > (if (= (modulo iter2 150) 0) > (begin; modulo true > (let ( [g (gcd prod2 n) ] ) > (if (and (> g 1) (< g n)) > (begin ; factor > (display "factor = ") (display g) (newline) > (display "iterations = ") (display iter2) (newline) > (set! done #t) > ) > (set! prod2 1) ; no factor > ) ; end if factor > ) ; end let > ) ; end begin for modulo true > #f ;action for modulo false > ) ; end major if > > (if (and (< iter2 max_iter) (not done)) > (rho n u1 v2 c iter2 prod2) > (if done ; either found factor or max iterations > (display "normal termination \n") > #f > ) ; if done > ) ; if and > ) ; end let* > ) > > (let ( [n (- (expt 2 257) 1)] [u 2] [v 11] [c 7] [iter 1] [prod 1] ) > (display "factor n = ") (display n) (newline) > (time (rho n u v c iter prod)) > ) > > ;;; Thanks for providing the program. Would it be ok to add it as a benchmark program to https://github.com/mario-goulart/chicken-benchmarks? All the best. Mario -- http://parenteses.org/mario
Re: Improve "busy" numeric code's performance [was: Re: Big Integers]
> On Wed, May 22, 2024 at 02:42:38PM +0200, Peter Bex wrote: > > Attached are two patches, one which has this bigger improvement, and > > another which is a minor improvement which translates to shaving about > > a second of runtime off your program (at least on my machine). > > The minor patch was incorrect. I copied some code from C_s_a_i_remainder > into C_s_a_i_modulo inline, but that code had an early return for the > case where both numbers are flonums. This code needs to be adjusted to > handle the case when the arguments aren't of the same sign, just like we > do after returning from integer_divrem(). > > I'm sending both patches again for your convenience. The second patch > has a fix for the aforementioned issue. > Appled - thanks! felix
Re: Improve "busy" numeric code's performance [was: Re: Big Integers]
On Wed, May 22, 2024 at 02:42:38PM +0200, Peter Bex wrote:
> Attached are two patches, one which has this bigger improvement, and
> another which is a minor improvement which translates to shaving about
> a second of runtime off your program (at least on my machine).
The minor patch was incorrect. I copied some code from C_s_a_i_remainder
into C_s_a_i_modulo inline, but that code had an early return for the
case where both numbers are flonums. This code needs to be adjusted to
handle the case when the arguments aren't of the same sign, just like we
do after returning from integer_divrem().
I'm sending both patches again for your convenience. The second patch
has a fix for the aforementioned issue.
Cheers,
Peter
>From d2999bb77a6ba8665be9ca997a85481b670705ea Mon Sep 17 00:00:00 2001
From: Peter Bex
Date: Wed, 22 May 2024 13:53:28 +0200
Subject: [PATCH 1/2] Don't free the memory for the scratchspace on minor GC
This is too costly if we're in a loop that's operating on the
scratchspace, because it will just reallocate the scratchspace, and
use a small scratchspace which will cause excessive reallocation.
---
runtime.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/runtime.c b/runtime.c
index 9becd2aa..5116ed37 100644
--- a/runtime.c
+++ b/runtime.c
@@ -3675,13 +3675,16 @@ C_regparm void C_fcall C_reclaim(void *trampoline,
C_word c)
}
/* GC will have copied any live objects out of scratch space: clear it */
- if (C_scratchspace_start != NULL) {
-C_free(C_scratchspace_start);
-C_scratchspace_start = NULL;
-C_scratchspace_top = NULL;
-C_scratchspace_limit = NULL;
+ if (C_scratchspace_start != C_scratchspace_top) {
+/* And drop the scratchspace in case of a major or reallocating collection
*/
+if (gc_mode != GC_MINOR) {
+ C_free(C_scratchspace_start);
+ C_scratchspace_start = NULL;
+ C_scratchspace_limit = NULL;
+ scratchspace_size = 0;
+}
+C_scratchspace_top = C_scratchspace_start;
C_scratch_usage = 0;
-scratchspace_size = 0;
}
if(gc_mode == GC_MAJOR) {
--
2.42.0
>From 24a7600f3766c0313ef2cbc611499c10e70b5d40 Mon Sep 17 00:00:00 2001
From: Peter Bex
Date: Wed, 22 May 2024 13:58:11 +0200
Subject: [PATCH 2/2] Call integer_divrem straight from the modulo operations
These would call C_s_a_i_remainder initially, which performs many of
the same checks that we've just already done before actually calling
integer_divrem. It also allocates more memory on the stack which is
not necessary.
In the case of the generic operator, doing so requires duplicating the
code which converts floating-point integers to exact integers and back
again.
In the case of the integer-specific operator, there's no point in
calling the *generic* remainder function in the first place!
---
runtime.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/runtime.c b/runtime.c
index 5116ed37..29dbcb00 100644
--- a/runtime.c
+++ b/runtime.c
@@ -9243,7 +9243,8 @@ C_s_a_u_i_integer_remainder(C_word **ptr, C_word n,
C_word x, C_word y)
C_regparm C_word C_fcall
C_s_a_i_modulo(C_word **ptr, C_word n, C_word x, C_word y)
{
- C_word ab[C_SIZEOF_FIX_BIGNUM], *a = ab, r;
+ C_word ab[C_SIZEOF_FIX_BIGNUM], *a = ab, r,
+ nx = C_SCHEME_FALSE, ny = C_SCHEME_FALSE;
if (!C_truep(C_i_integerp(x)))
barf(C_BAD_ARGUMENT_TYPE_NO_INTEGER_ERROR, "modulo", x);
@@ -9251,13 +9252,41 @@ C_s_a_i_modulo(C_word **ptr, C_word n, C_word x, C_word
y)
barf(C_BAD_ARGUMENT_TYPE_NO_INTEGER_ERROR, "modulo", y);
if (C_truep(C_i_zerop(y))) C_div_by_zero_error("modulo");
- r = C_s_a_i_remainder(, 2, x, y);
- if (C_i_positivep(y) != C_i_positivep(r) && !C_truep(C_i_zerop(r))) {
+ if (C_truep(C_i_flonump(x))) {
+if C_truep(C_i_flonump(y)) {
+ double dx = C_flonum_magnitude(x), dy = C_flonum_magnitude(y), tmp;
+
+ C_modf(dx / dy, );
+ tmp = dx - tmp * dy;
+ if ((dx > 0.0) != (dy > 0.0) && tmp != 0.0) {
+return C_flonum(ptr, tmp + dy);
+ } else {
+return C_flonum(ptr, tmp);
+ }
+}
+x = nx = C_s_a_u_i_flo_to_int(, 1, x);
+ }
+ if (C_truep(C_i_flonump(y))) {
+y = ny = C_s_a_u_i_flo_to_int(, 1, y);
+ }
+
+ integer_divrem(, x, y, NULL, );
+ if (C_i_positivep(y) != C_i_positivep(r) && r != C_fix(0)) {
C_word m = C_s_a_i_plus(ptr, 2, r, y);
m = move_buffer_object(ptr, ab, m);
clear_buffer_object(ab, r);
r = m;
}
+
+ if (C_truep(nx) || C_truep(ny)) {
+C_word newr = C_a_i_exact_to_inexact(ptr, 1, r);
+clear_buffer_object(ab, r);
+r = newr;
+
+clear_buffer_object(ab, nx);
+clear_buffer_object(ab, ny);
+ }
+
return move_buffer_object(ptr, ab, r);
}
@@ -9267,7 +9296,7 @@ C_s_a_u_i_integer_modulo(C_word **ptr, C_word n, C_word
x, C_word y)
C_word ab[C_SIZEOF_FIX_BIGNUM], *a = ab, r;
if (y == C_fix(0)) C_div_by_zero_error("modulo");
- r = C_s_a_i_remainder(, 2,
Improve "busy" numeric code's performance [was: Re: Big Integers]
> (if done ; either found factor or max iterations (display "normal
> termination \n") #f ) ; if done ) ; if and ) ; end let*)
> (let ( [n (- (expt 2 257) 1)] [u 2] [v 11] [c 7] [iter 1] [prod 1] )
> (display "factor n = ") (display n) (newline) (time (rho n u v c iter
> prod)))
> ;;;
> On Tuesday, May 21, 2024 at 12:13:55 AM MDT, Peter Bex
> wrote:
>
> (sending again, forgot to CC the users list)
>
> On Mon, May 20, 2024 at 03:23:54PM +, T.D. Telford wrote:
> > With the csc compiler and the -f or -fixnum-arithmetic option (Assume all
> > numbers are fixnums) my benchmarks appear to be quite fast compared to
> > racket of chez scheme. When running a benchmark that uses big integers
> > (such as the pollard rho), execution times are almost twice as long as
> > racket or chez.
>
> Hello there!
>
> When we initially added bignum support in core (it used to be an egg),
> we spent quite a bit of effort optimizing various benchmarks, and
> on several of these (but not all of course), at the end CHICKEN
> performed *better* than several other Schemes, including Racket (which
> wasn't Chez-based at the time). It's quite possible that Chez Scheme
> has some optimized routines that other Schemes don't have, which we
> could learn from.
>
> If you have a specific benchmark that's slow, it would be helpful if you
> could share the code so we can have a look what it is exactly that slows
> things down.
>
> > Is there an egg or alternate code to improve the efficiency of big
> > integers? I would have thought there would be interface to gmp.
>
> While GMP is optimized to the hilt, it won't necessarily improve speed.
> The original "numbers" egg which provided add-on support for bignums
> was based on GMP and slow as molasses. Mediocre numeric code that's
> deeply integrated with the garbage collector and compilation strategy
> can easily outperform supremely bummed code that has to go through the
> FFI on every call.
>
> Again, if you can share some benchmarking code we can have a look if
> there are any obvious bottlenecks.
>
> Cheers,
> Peter
>
> ;; recursive
> ;;#lang racket;; uncomment for racket
>
>
> (define (rho n u v c iter prod)
> (let* ( [u1 (modulo (+ (* u u) c) n)]
> [v1 (modulo (+ (* v v) c) n)]
> [v2 (modulo (+ (* v1 v1) c) n)]
> [done #f]
> [max_iter 3000]
> [iter2 (+ iter 1)]
> [prod2 (modulo (* prod (- u1 v2)) n)] )
>
> (if (= (modulo iter2 150) 0)
> (begin; modulo true
> (let ( [g (gcd prod2 n) ] )
> (if (and (> g 1) (< g n))
> (begin ; factor
> (display "factor = ") (display g) (newline)
> (display "iterations = ") (display iter2) (newline)
> (set! done #t)
> )
> (set! prod2 1) ; no factor
> ) ; end if factor
> ) ; end let
> ) ; end begin for modulo true
> #f ;action for modulo false
> ) ; end major if
>
> (if (and (< iter2 max_iter) (not done))
> (rho n u1 v2 c iter2 prod2)
> (if done ; either found factor or max iterations
> (display "normal termination \n")
> #f
> ) ; if done
> ) ; if and
> ) ; end let*
> )
>
> (let ( [n (- (expt 2 257) 1)] [u 2] [v 11] [c 7] [iter 1] [prod 1] )
> (display "factor n = ") (display n) (newline)
> (time (rho n u v c iter prod))
> )
>
>From d2999bb77a6ba8665be9ca997a85481b670705ea Mon Sep 17 00:00:00 2001
From: Peter Bex
Date: Wed, 22 May 2024 13:53:28 +0200
Subject: [PATCH 1/2] Don't free the memory for the scratchspace on minor GC
This is too costly if we're in a loop that's operating on the
scratchspace, because it will just reallocate the scratchspace, and
use a small scratchspace which will cause excessive reallocation.
---
runtime.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/runtime.c b/runtime.c
index 9becd2aa..5116ed37 100644
--- a/runtime.c
+++ b/runtime.c
@@ -3675,13 +3675,16 @@ C_regparm void C_fcall C_reclaim(void *trampoline,
C_word c)
}
/* GC will have copied any live objects out of scratch space: clear it */
- if (C_scratchspace_start != NULL) {
-C_free(C_scratchspace_start);
-C_scratchspace_start = NULL;
-C_scratchspace_top = NULL;
-C_scratchspace_limit = NULL;
+ if (C_scratchspace_start != C_scratchspace_top) {
+/* And drop the scratchspace in case of a major or reallocating coll
Big Integers on Chicken
Hello Peter, I should have mentioned that I am using linux mint 21.3 Regards,Doug
Re: Big Integers
Hello Peter, Thanks for the reply. The elapsed timings for the program rho3rec are: chicken 5.3.0: 33.6 secondsRacket v8.2 [cs] : 18.1 secondsDr Racket : 20.6 seconds (1 MB memory) The program uses the Pollard rho algorithm to find a factor of 2^257 -1. The program is highly recursive, but I have a non recursive version that has the same timing as the above. I am using an AMD Ryzen 5600 cpu and 32 GB of main memory. I tried all of the csc options that appeared related to speed, and the maximum improvement was 0.1 seconds. The one option I did not get to work was -heap-size 1000M where I varied the size from 1000M to 1M. In all cases I would get the run time message[panic] out of memory - heap full - execution terminated I have include the program listing below and also as an attachment. Regards,Doug ;#lang racket ;; uncomment for racket (define (rho n u v c iter prod) (let* ( [u1 (modulo (+ (* u u) c) n)] [v1 (modulo (+ (* v v) c) n)] [v2 (modulo (+ (* v1 v1) c) n)] [done #f] [max_iter 3000] [iter2 (+ iter 1)] [prod2 (modulo (* prod (- u1 v2)) n)] ) (if (= (modulo iter2 150) 0) (begin ; modulo true (let ( [g (gcd prod2 n) ] ) (if (and (> g 1) (< g n)) (begin ; factor (display "factor = ") (display g) (newline) (display "iterations = ") (display iter2) (newline) (set! done #t) ) (set! prod2 1) ; no factor ) ; end if factor ) ; end let ) ; end begin for modulo true #f ;action for modulo false ) ; end major if (if (and (< iter2 max_iter) (not done)) (rho n u1 v2 c iter2 prod2) (if done ; either found factor or max iterations (display "normal termination \n") #f ) ; if done ) ; if and ) ; end let*) (let ( [n (- (expt 2 257) 1)] [u 2] [v 11] [c 7] [iter 1] [prod 1] ) (display "factor n = ") (display n) (newline) (time (rho n u v c iter prod))) ;;; On Tuesday, May 21, 2024 at 12:13:55 AM MDT, Peter Bex wrote: (sending again, forgot to CC the users list) On Mon, May 20, 2024 at 03:23:54PM +, T.D. Telford wrote: > With the csc compiler and the -f or -fixnum-arithmetic option (Assume all > numbers are fixnums) my benchmarks appear to be quite fast compared to racket > of chez scheme. When running a benchmark that uses big integers (such as the > pollard rho), execution times are almost twice as long as racket or chez. Hello there! When we initially added bignum support in core (it used to be an egg), we spent quite a bit of effort optimizing various benchmarks, and on several of these (but not all of course), at the end CHICKEN performed *better* than several other Schemes, including Racket (which wasn't Chez-based at the time). It's quite possible that Chez Scheme has some optimized routines that other Schemes don't have, which we could learn from. If you have a specific benchmark that's slow, it would be helpful if you could share the code so we can have a look what it is exactly that slows things down. > Is there an egg or alternate code to improve the efficiency of big integers? > I would have thought there would be interface to gmp. While GMP is optimized to the hilt, it won't necessarily improve speed. The original "numbers" egg which provided add-on support for bignums was based on GMP and slow as molasses. Mediocre numeric code that's deeply integrated with the garbage collector and compilation strategy can easily outperform supremely bummed code that has to go through the FFI on every call. Again, if you can share some benchmarking code we can have a look if there are any obvious bottlenecks. Cheers, Peter ;; recursive ;;#lang racket;; uncomment for racket (define (rho n u v c iter prod) (let* ( [u1 (modulo (+ (* u u) c) n)] [v1 (modulo (+ (* v v) c) n)] [v2 (modulo (+ (* v1 v1) c) n)] [done #f] [max_iter 3000] [iter2 (+ iter 1)] [prod2 (modulo (* prod (- u1 v2)) n)] ) (if (= (modulo iter2 150) 0) (begin; modulo true (let ( [g (gcd prod2 n) ] ) (if (and (> g 1) (< g n)) (begin ; factor (display "factor = ") (display g) (newline) (display "iterations = ") (display iter2) (newline) (set! done #t) ) (set! prod2 1) ; no factor ) ; end if factor ) ; end let ) ; end begin for modulo true #f ;action for modulo false ) ; end major if (if (and (< iter2 max_iter) (not done)) (rho n u1 v2 c iter2 prod2)
Re: Big Integers
(sending again, forgot to CC the users list) On Mon, May 20, 2024 at 03:23:54PM +, T.D. Telford wrote: > With the csc compiler and the -f or -fixnum-arithmetic option (Assume all > numbers are fixnums) my benchmarks appear to be quite fast compared to racket > of chez scheme. When running a benchmark that uses big integers (such as the > pollard rho), execution times are almost twice as long as racket or chez. Hello there! When we initially added bignum support in core (it used to be an egg), we spent quite a bit of effort optimizing various benchmarks, and on several of these (but not all of course), at the end CHICKEN performed *better* than several other Schemes, including Racket (which wasn't Chez-based at the time). It's quite possible that Chez Scheme has some optimized routines that other Schemes don't have, which we could learn from. If you have a specific benchmark that's slow, it would be helpful if you could share the code so we can have a look what it is exactly that slows things down. > Is there an egg or alternate code to improve the efficiency of big integers? > I would have thought there would be interface to gmp. While GMP is optimized to the hilt, it won't necessarily improve speed. The original "numbers" egg which provided add-on support for bignums was based on GMP and slow as molasses. Mediocre numeric code that's deeply integrated with the garbage collector and compilation strategy can easily outperform supremely bummed code that has to go through the FFI on every call. Again, if you can share some benchmarking code we can have a look if there are any obvious bottlenecks. Cheers, Peter
Big Integers
With the csc compiler and the -f or -fixnum-arithmetic option (Assume all numbers are fixnums) my benchmarks appear to be quite fast compared to racket of chez scheme. When running a benchmark that uses big integers (such as the pollard rho), execution times are almost twice as long as racket or chez. Is there an egg or alternate code to improve the efficiency of big integers? I would have thought there would be interface to gmp.
[Chicken-users] Big integers as statement parameters in sql-de-lite
Hi, chickenists-- I am working on an application that stores data in a SQLite3 database, and am currently using the sql-de-lite egg to interface with the DB. I have a few fields that represent dates, and I have defined their datatype as INTEGER. However, when I attempt to execute a statement such as: INSERT INTO articles (node_id, title, created_dt) VALUES (?, ?, ?); with one of these large integers bound to the third parameter, I get an error because apparently the value is too large. The values in question are obtained in the following manner: (time-seconds (date-time SRFI-19-DATE-OBJECT)) ... so a typical result is a number like 1291678156, which is a bignum. Is there a way I can use these numbers as numbers in sql-de-lite, or do I have to convert them to something else? -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Big integers as statement parameters in sql-de-lite
On Jul 22, 2013, at 3:26 PM, Matt Gushee m...@gushee.net wrote: Hi, chickenists-- I am working on an application that stores data in a SQLite3 database, and am currently using the sql-de-lite egg to interface with the DB. I have a few fields that represent dates, and I have defined their datatype as INTEGER. However, when I attempt to execute a statement such as: INSERT INTO articles (node_id, title, created_dt) VALUES (?, ?, ?); with one of these large integers bound to the third parameter, I get an error because apparently the value is too large. The values in question are obtained in the following manner: (time-seconds (date-time SRFI-19-DATE-OBJECT)) ... so a typical result is a number like 1291678156, which is a bignum. Is there a way I can use these numbers as numbers in sql-de-lite, or do I have to convert them to something else? (SQLite3 does have datetime functions for use in queries but assumes a string or UNIX timestamp.) Do you need the range a SRFI-19 datetime provides? Maybe an epoch based approach, like provided by the posix module. -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Big integers as statement parameters in sql-de-lite
It's not that the values are too large, it's that srfi 19 represents them as bignums, which is not currently supported by sql-de-lite. However, they work as floats (they will be converted to integers before being passed to the database, due to the column type). Even on 32-bit systems, we fully support handling 53 bit integers in the database in this way. The easiest way to do this is by calling exact-inexact on the result to force it to floating point. Such a small value need not be a flonum on 64-bit system, but it will still work correctly, and it's the easiest way to ensure it is not a bignum. You can confirm the value was stored as an integer by using the typeof() SQL function, e.g. select typeof(date) from foo; Or you can just store the UNIX timestamp obtained from the posix unit, which should be a lot easier ;) Jim On Jul 22, 2013, at 18:18, Matt Gushee m...@gushee.net wrote: Hi, Kon-- On Mon, Jul 22, 2013 at 4:34 PM, Kon Lovett konlov...@gmail.com wrote: Do you need the range a SRFI-19 datetime provides? Maybe an epoch based approach, like provided by the posix module. No, I don't need the range. In fact, my project is a lightweight blogging platform, and the date-times in question are creation and modification times for the content, which will normally be displayed to site visitors--possibly in localized formats; and other values having to do with authentication and sessions, which will normally be invisible. So I think it is safe to assume that all values that will ever be used will fall within a couple of decades beginning with 2013. I'm not sure if I need to use SRFI-19. For some reason I thought that it would be preferable from the POV of localized formatting and time zone conversions, but looking again at the docs it doesn't seem like that is necessary. But I notice that the posix date/time functions work with values representing seconds, much like the values that are not working for me--except that in posix they are floats instead of integers. So maybe they won't cause errors? I'll give that a try. -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
