|
From: Hugo C. <hug...@gm...> - 2018-07-02 09:57:34
|
Thanks a lot! On Sun, 1 Jul 2018, 22:41 Stavros Macrakis (Σταῦρος Μακράκης), < mac...@al...> wrote: > The core of the continued fraction routines dates to the 1970s. > No conceptual work has been done to them since then, though some > ill-thought-out enhancements have been made. > > For example, a minor addition from 2007 supports non-square roots, e.g., > cf(2^(1/3)), by using the floor function, which uses approximate evaluation > (bfloat) and ratsimp. But that isn't even documented, and it is poorly > integrated: that code lets cf((1/2)^(1/3)) give a correct result, but > cf((1/2)^(1/2)) gives an error! It also interprets cflength differently > from the rest of cf (also undocumented). > > In fact, the approximation approach works fine for other functions as > well; it just isn't exposed to the user. For example, cf(sin(1)) gives an > error, but ?cfnroot(sin(1)),cflength:10 happily returns [0, 1, 5, 3, 4, 19, > 2, 2, 2, 2]. But you might as well write cf(bfloat(sin(1))) and control the > precision more accurately. For that matter, ?cfnroot(sin(1)),cflength:30 > gives the error "expt undefined: 0 to a negative exponent". > > The cfnroot approximation technique is absurdly inefficient, as well. For > example, cf(2^(1/10)),cflength:4 takes 56 sec (you can see why by tracing > ratsimp with cflength:2), whereas cf(bfloat(2^(1/10))) gives 17 terms in < > 1 ms. > > All that to say that there is no one working on CF seriously. > > As for checking theorems about CFs, you will probably find cfdisrep useful > for that. > > -s > > > > > > > > > > > On Sun, Jul 1, 2018 at 4:36 AM Hugo Coolens <hug...@gm...> wrote: > >> >> >> 2018-06-29 19:10 GMT+02:00 Stavros Macrakis (Σταῦρος Μακράκης) < >> mac...@al...>: >> >>> The cf group of functions is a *horribly designed hack*. >>> >>> The hack of supporting [...]*[...] within the cf function is an >>> abomination which wrecks referential transparency: >>> >>> qq: [2,3]*[4,5] => [8,15] (with listarith: true, the default) >>> cf(qq) => [8,15] >>> cf([2,3]*[4,5]) => [9,1,4] >>> >>> >>> It is also an abomination because it only supports * and not / and >>> integer ^. >>> >>> It is also an abomination because it gives incorrect results when >>> there's more than one repeating cf: >>> >>> cf(sqrt(2)*sqrt(5)) => [3,2,1,2] >>> cf(sqrt(10)) => [3,6] >>> >>> For that matter, it is an abomination that cf(sqrt(...)) doesn't >>> indicate in any way that the result repeats, or what the repeating group is. >>> >>> As I understand it, the "continued fractions part" of Maxima is not well >> developed at this very moment and barely useable? >> Is there a chance it will be replaced by something better in the (near) >> future? >> >> >> >>> As for performing cf manipulations symbolically, what do you have in >>> mind? >>> >>> I was going to check some theorems concerning cf's symbolically with >> Maxima >> >> >> >>> In particular, what is cf([a]/[0,b]) == cf(a/b)? After all, cf(5/5) = >>> [1], cf(5/7) = [0,1,2,2], cf(5/11) = [0,2,5], cf(5/13) = [0,2,1,1,2], >>> cf(5/15) = [0,3], etc. Not even the length is constant. >>> >>> >>> >>> >>> >>> On Fri, Jun 29, 2018 at 8:09 AM Hugo Coolens <hug...@gm...> >>> wrote: >>> >>>> Is it possible to perform symbolic math with continued fractions? >>>> If I try something like this: >>>> cf([a,b,c]); >>>> maxima answers with >>>> Maxima encountered a Lisp error: Condition in MACSYMA-TOP-LEVEL [or a >>>> callee]: INTERNAL-SIMPLE-TYPE-ERROR: $C is not of type NUMBER: >>>> >>>> can I tell maxima a,b and are of type NUMBER? >>>> >>>> kind regards, >>>> Hugo >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Maxima-discuss mailing list >>>> Max...@li... >>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >>>> >>> >> |