You can subscribe to this list here.
2014 
_{Jan}

_{Feb}
(232) 
_{Mar}
(323) 
_{Apr}
(383) 
_{May}
(359) 
_{Jun}
(435) 
_{Jul}
(252) 
_{Aug}
(172) 
_{Sep}
(265) 
_{Oct}
(263) 
_{Nov}
(350) 
_{Dec}
(359) 

2015 
_{Jan}
(267) 
_{Feb}
(220) 
_{Mar}
(311) 
_{Apr}
(269) 
_{May}
(388) 
_{Jun}
(403) 
_{Jul}
(172) 
_{Aug}
(399) 
_{Sep}
(364) 
_{Oct}
(269) 
_{Nov}
(331) 
_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6

7
(1) 
8

9
(3) 
10
(3) 
11
(1) 
12
(7) 
13
(8) 
14
(13) 
15
(18) 
16
(13) 
17
(11) 
18
(17) 
19
(25) 
20
(22) 
21
(10) 
22
(2) 
23
(16) 
24
(5) 
25
(11) 
26
(10) 
27
(10) 
28
(26) 

From: Jorge Calvo <Jorge.C<alvo@av...>  20140219 23:16:16

Hi Raymond: I have discovered that in a small classroom of 9 students running different versions of Maxima (downloaded at different times) on different platforms I get all three types of behaviors I mentioned. A few months back (Thu, 4 Apr 2013), Volker van Nek <volkervannek@...<mailto:volkervannek@...>> graciously posted some computations for me on a i686pclinuxgnu with a variety of Lisp implementation types. He reported that given an input of 4e324, SBCL and CLISP rounded down to 0.0, ECL rounded up to 4.940656458412466e324, Clozure Common Lisp rounded up to 5.0E324, GCL converted to 4.0d324, and CMU Common Lisp produced an error. I was a little puzzled over what 4.0d324 meant, but a bit of searching online led me to the conclusion that it must be a fixedpoint number… whatever that might be. Perhaps there is a bit of COBOL lurking underneath GCL? At any rate, all of the Linux and Window 7 machines that I've met this semester seem to go that way. Weird, huh? Jorge Raymond Toy <toy.raymond@...<mailto:toy.raymond@...>> wrote: I tried ... (format t "~%~e" 4d324) 4.9406564584124657d324 Allegro Common Lisp 4.9406564584124654E324 GCL 0.0d+0 SBCL all on Windows 
From: Richard Fateman <fateman@be...>  20140219 22:09:30

On 2/19/2014 1:45 PM, Stavros Macrakis wrote: > It seems to me that  if this is a good idea at all  the correct > implementation of automatic conversion of floats to bfloats would have > one simple property: if floats cannot faithfully represent a number to > the nominal precision, it should convert to bfloat. Well, this is (centrally) about precision, but about exponent range. Though I suppose precision could play into the notion of conversion if the bfloat default precision is crazy small. One of the fundamental ideas and consequent constraints of floatingpoint is that each number can use only a fixed number of bits. (like 64). And we are breaking that by allowing overflow to bigfloats. The way I mentioned earlier that I used was to code an exceptional number (like overflowed something) as a NaN, but with the "mantissa" part being a pointer into an array, where some other representation is stored. Like a bigfloat. What this means is that it is potentially possible for an ordinary piece of lisp code like (+ a b) to trap because a and/or b is coded as a NaN which means the actual value(s) are bigfloats stored in a table. The result is probably then another NaN (= bigfloat stored in that table). If you allow that table to also store symbols like x, y, z, or expressions exp(z), sin(x+y), ... then you could have an entire computer algebra system implemented underthecovers via trap handling of a floatingpoint system. But if you want only bigfloats, that's ok with me. Can all our lisps uniformly do the handlerbinding / catch/ throw/ hacking NaNs? RJF > > This means that if the exponent is out of range, or if the mantissa is > not fullprecision, then the number should be calculated as bfloat. In > particular, gradual underflow (denormalized numbers) should be treated > as underflow, and the result calculated as a bfloat: (5e320/3)*3. > Similarly, the input number 5e320 should be read as the bfloat > 5.0b320, not the float 4.99994e320. > > I don't know if that is practical with current Lisp implementations, > but without that property, it seems to me that we are giving the user > the /illusion/ of getting bfloat properties, not the reality. > > s > > > On Wed, Feb 19, 2014 at 4:35 PM, Stavros Macrakis > <macrakis@... <mailto:macrakis@...>> wrote: > > On Wed, Feb 19, 2014 at 4:08 PM, Raymond Toy > <toy.raymond@... <mailto:toy.raymond@...>>wrote: > > 4e324 is smaller than leastpositivedoublefloat (approx > 4.94065d324), so I would > e > xpect either an error saying it's not > representable or 0.0. > > > Hmm, I would expect it to round to 4.94e324, because it is closer > to that than it is to zero. > > s > > > > > >  > Managing the Performance of CloudBased Applications > Take advantage of what the Cloud has to offer  Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Richard Fateman <fateman@be...>  20140219 21:57:33

I tried ... (format t "~%~e" 4d324) 4.9406564584124657d324 Allegro Common Lisp 4.9406564584124654E324 GCL 0.0d+0 SBCL all on Windows 
From: Stavros Macrakis <macrakis@al...>  20140219 21:46:07

It seems to me that  if this is a good idea at all  the correct implementation of automatic conversion of floats to bfloats would have one simple property: if floats cannot faithfully represent a number to the nominal precision, it should convert to bfloat. This means that if the exponent is out of range, or if the mantissa is not fullprecision, then the number should be calculated as bfloat. In particular, gradual underflow (denormalized numbers) should be treated as underflow, and the result calculated as a bfloat: (5e320/3)*3. Similarly, the input number 5e320 should be read as the bfloat 5.0b320, not the float 4.99994e320. I don't know if that is practical with current Lisp implementations, but without that property, it seems to me that we are giving the user the *illusion* of getting bfloat properties, not the reality. s On Wed, Feb 19, 2014 at 4:35 PM, Stavros Macrakis <macrakis@...>wrote: > On Wed, Feb 19, 2014 at 4:08 PM, Raymond Toy <toy.raymond@...>wrote: > >> 4e324 is smaller than leastpositivedoublefloat (approx >> 4.94065d324), so I would >> e >> xpect either an error saying it's not >> representable or 0.0. >> > > Hmm, I would expect it to round to 4.94e324, because it is closer to that > than it is to zero. > > s > > > 
From: Raymond Toy <toy.raymond@gm...>  20140219 21:44:16

>>>>> "Stavros" == Stavros Macrakis <macrakis@...> writes: Stavros> On Wed, Feb 19, 2014 at 4:08 PM, Raymond Toy <toy.raymond@...> wrote: Raymond> 4e324 is smaller than leastpositivedoublefloat Raymond> (approx 4.94065d324), so I would expect either an error Raymond> saying it's not representable or 0.0. Stavros> Hmm, I would expect it to round to 4.94e324, because it Stavros> is closer to that than it is to zero. Good point. I'm not aware of any lisp that does that, but perhaps they should. Ray 
From: Stavros Macrakis <macrakis@al...>  20140219 21:35:55

On Wed, Feb 19, 2014 at 4:08 PM, Raymond Toy <toy.raymond@...> wrote: > 4e324 is smaller than leastpositivedoublefloat (approx > > 4.94065d324), so I would > e > xpect either an error saying it's not > > representable or 0.0. > Hmm, I would expect it to round to 4.94e324, because it is closer to that than it is to zero. s 
From: Richard Fateman <fateman@be...>  20140219 21:09:40

On 2/19/2014 11:52 AM, Mark wrote: > On 02/19/2014 08:13 PM, Robert Dodier wrote: >> On 20140219, Mark <zeitlinie@...> wrote: >> >>> Apart from the maxima manual, is there any other recommended howto >>> documentation for using rules and patterns in Maxima? >> No, but feel free to post any questions about rules & patterns to the mailing list. >> >>> I tried working with the 2nd eds. of Macsyma's user guide, but there are >>> differences between Macsyma and Maxima for me right away. E.g. if I >>> simply copycutandpaste the famous example to implement the factorial >>> using rules (pg. 220), then, tellsimpafter() is not applied recursively, >>> but only once. 1. I wrote the pattern matcher circa 1969 at MIT. 2. WGD changed it, substituting his own version, in the Symbolics version in 1986. (according to comments not in the Maxima code) 3. Apparently the semantics in this case differ. I do not know if this was intentional or not. 4. The use of tellsimpafter shown in the user manual is not how it is intended to be used. It might be too strong to say the example is a bug, but perhaps it is. I do not know who wrote the user manual, but the IDEA behind tellsimpafter is that it should be used when there is some perhaps quite powerful builtin simplification mechanism in Macsyma that you don't want to coerce or override, but that you wanted to advise in a kind of final checkup. That is, if the builtin simplifier left some form unchanged, then you could turn to your own program. e.g. tellsimpafter(integrate(EXP,x), f(x)) would be used only if the builtin integrate command did not work, but you knew how to integrate EXP. Tellsimpafter COULD be used to modify a simplifier that you constructed yourself with layers of tellsimp() and perhaps tellsimpafter() interlayered. Sounds like a bad design, but in the case here, where the rule set strictly defines the domain (positive integers vs anything else), the ordering of the rules doesn't matter! The use of tellsimpafter to define a new function is inappropriate generally. The use of tellsimpafter to modify the simplification of function foo, where the replacement contains foo is an invitation to disaster  or at least it seemed to me, in 1969. So I disallowed resimplification. Allowing resimplification is probably a change of a dozen characters or so, and WGD presumably did that, realizing that my fear was not especially well founded, and that potentially infinite recursion could be stopped by appropriate ordering of rules. I assume that WGD also modernized the code in various ways. To me, the appropriate code for a rulebased factorial that just leaves nonintegers or negative numbers hanging would be posintp(n):=is(integerp(n) and n>0)$ matchdeclare(int,posintp)$ tellsimp(fact(0),1)$ tellsimp(fact(int),int*fact(int1))$ There is no reason to use tellsimpAFTER here. Why did the userguide author use it? >> That sounds interesting, but as I don't have the Macsyma user guide at >> hand, I can't try out that example. Care to post the code in question? > Before I do that, may I ask if you would think that the docs for the > pattern matcher in Macsyma should be onetoone usable also for Maxima? I would have thought so. It could be that WGD introduced other differences. I noticed one, which is that tellsimp(exp1,exp2,cond) is acceptable. the third argument cond is a conditional which is evaluated, and if false, inhibits the rule. So any examples that you encounter that use that feature will not work in Maxima currently. I haven't spotted any examples in the Macsyma user manual and its online help system neglects to mention this feature. In the Macsyma system then, only one rule would be needed... matchdeclare(int,true); tellsimp(fact(int),int*fact(int1), integerp(int) and int>0); this is not acceptable to Maxima. > > This is the code from pg. 220 of Macsyma User's Guide 2nd. Ed. (Google > tells you to get it from > http://www.cs.berkeley.edu/~fateman/macsyma/docs/userg.pdf) Yes, that's a place to find it. You can also find the reference manual in that directory. Nice of Google to find it for you. > > (c1) posintp(n):=is(integerp(n) and n>0)$ > (c2) matchdeclare(int,posintp)$ > (c3) tellsimpafter(fact(0),1)$ > (c4) tellsimpafter(fact(int),int*fact(int1))$ > (c5) fact(1) > (d5) fact( 1) > (c6) fact(0.5) > (d6) fact(0.5) > (c7) fact(0) > (d7) 1 > (c8) fact(5) > (d8) 120 > > This makes sense to me, if I should think of tellsimpafter() to work > recursively until the rule cannot be applied any more. As far as I can recall, that's not the way the original author thought it should work, but it is the way WGD changed it (Bill Dubuque, where are you?) > > Now this is what happens if I (, admittedly, completely blindly) type in > the same lines into a freshly started Maxima > > <snip>; > > (%i9) fact(5); > (%o9) 5*fact(4) > > (d8) vs. (%o9) is what I was asking about. > > Mark > > 
From: Raymond Toy <toy.raymond@gm...>  20140219 21:09:14

>>>>> "Rupert" == Rupert Swarbrick <rswarbrick@...> writes: Rupert> Jorge Calvo <Jorge.Calvo@...> writes: >> Hi there! >> >> I was doing a little exploration of underflow errors  mostly to >> explain the IEEE754 standard to my students  and noticed that in >> some cases, underflows are handled differently based on the underlying >> platform. For instance, found that 4e324 (entered straight from the >> prompt) rounds down to 0.0 in a Mac, up to 4.94065… x 10^324 in older 4e324 is smaller than leastpositivedoublefloat (approx 4.94065d324), so I would expect either an error saying it's not representable or 0.0. >> Windows machines, and is converted to the fixedpoint number 4.0d324 >> in Linux and newer Windows machines. It's really the underlying Lisp What version of maxima are you using? I don't see how you can get 4.0d324 on any of those machines. I'm also not sure what you mean by a fixedpoint number in this case. >> that seems to make a difference, but my point is that I don't know >> that any one of these behaviors is preferable over the others. Would >> your plan be to force conversion to bigfloats in place of any of these >> choices? >> >> Somewhat ambivalent... >> >> Jorge Rupert> I'm not entirely sure what I am in favour of either, so am hoping people Rupert> with more experience will weigh in. Rupert> But my initial thought was Rupert> 1eLOTS => 0.0 Rupert> is absolutely fine, whereas Rupert> (%i56) (1e100)^4; Rupert> (%o56) 0.0 Rupert> is a bit more unfortunate. But I'm pretty unsure about how this would This is the answer I would expect from an IEEE754 machine, with underflow traps turned off. I want to be able to do some "serious"[1] floatingpoint work with maxima, so, assuming an underlying lisp (like ccl, cmucl, sbcl, and maybe others that I'm not so familiar with) that is pretty serious about correct floatingpoint arithmetic, I want things to work as would be expected for IEEE754. Ray Footnotes: [1] "Serious" meaning bit exact, not intensive numerical work. 
From: Steve Haflich <shaflich@gm...>  20140219 20:29:07

I have some experience with compiling floating point operations, but that was long ago and I'm unsure about details of current processors. But here is some advice about testing fp edge cases. Most fp processors have some control state that affects how various situations are treated, eg rounding modes and whether overflow and underfloor produce values ours signal exceptions. If such controls are still in current processors, that's useful, but code needs to be written and compiled with knowledge of what those modes will be. Modes may need to be setup at start, and more importantly, if a subroutine wants something different, it must dry the desired state and be careful to restore state when returning to the caller. Routines that fail to do this cause subtle errors and misbehavior that can be hard to diagnose. Anyway, I don't deal with this kind of stuff any more, and don't know if it is an issue with current CPUs, but it's something to keep on mind. 
From: Mark <zeitlinie@ya...>  20140219 19:52:18

On 02/19/2014 08:13 PM, Robert Dodier wrote: > On 20140219, Mark <zeitlinie@...> wrote: > >> Apart from the maxima manual, is there any other recommended howto >> documentation for using rules and patterns in Maxima? > > No, but feel free to post any questions about rules & patterns to the mailing list. > >> I tried working with the 2nd eds. of Macsyma's user guide, but there are >> differences between Macsyma and Maxima for me right away. E.g. if I >> simply copycutandpaste the famous example to implement the factorial >> using rules (pg. 220), then, tellsimpafter() is not applied recursively, >> but only once. > > That sounds interesting, but as I don't have the Macsyma user guide at > hand, I can't try out that example. Care to post the code in question? Before I do that, may I ask if you would think that the docs for the pattern matcher in Macsyma should be onetoone usable also for Maxima? This is the code from pg. 220 of Macsyma User's Guide 2nd. Ed. (Google tells you to get it from http://www.cs.berkeley.edu/~fateman/macsyma/docs/userg.pdf) (c1) posintp(n):=is(integerp(n) and n>0)$ (c2) matchdeclare(int,posintp)$ (c3) tellsimpafter(fact(0),1)$ (c4) tellsimpafter(fact(int),int*fact(int1))$ (c5) fact(1) (d5) fact( 1) (c6) fact(0.5) (d6) fact(0.5) (c7) fact(0) (d7) 1 (c8) fact(5) (d8) 120 This makes sense to me, if I should think of tellsimpafter() to work recursively until the rule cannot be applied any more. Now this is what happens if I (, admittedly, completely blindly) type in the same lines into a freshly started Maxima (%i1) display2d:false$ (%i2) posintp(n):=is(integerp(n) and n>0)$ (%i3) matchdeclare(int,posintp)$ (%i4) tellsimpafter(fact(0),1)$ (%i5) tellsimpafter(fact(int),int*fact(int1))$ (%i6) fact(1); (%o6) fact(1) (%i7) fact(0.5); (%o7) fact(0.5) (%i8) fact(0); (%o8) 1 (%i9) fact(5); (%o9) 5*fact(4) (d8) vs. (%o9) is what I was asking about. Mark 
From: Jorge Calvo <Jorge.C<alvo@av...>  20140219 19:21:31

At this point, I haven't devised a good test to see if the problem is in READING or DISPLAYING floats. I suspect both. If I understand IEEE754 correctly, 4e324 should round up since the truncated bits are (1, 1, 0, …), which is what the older Windows machines do. I have no idea why my Mac goes the other way… :) Jorge On Feb 19, 2014, at 12:00 PM, Richard Fateman wrote: > I suspect that there are bugs in READING very small floats  the reading program may be using floats in a way that > causes an overflow or underflow, and thus gets the wrong answer. > > I suggest that if you want to experiment with small numbers that you construct them by starting with 2.0d0 and > multiplying, dividing, shifting etc. > > There is also a matter of whether gradual underflow is implemented or supported by the implementation > (hardware or software). > > > On 2/19/2014 8:07 AM, Jorge Calvo wrote: >> Hi there! >> >> I was doing a little exploration of underflow errors  mostly to explain the IEEE754 standard to my students  and noticed that in some cases, underflows are handled differently based on the underlying platform. For instance, found that 4e324 (entered straight from the prompt) rounds down to 0.0 in a Mac, up to 4.94065… x 10^324 in older Windows machines, and is converted to the fixedpoint number 4.0d324 in Linux and newer Windows machines. It's really the underlying Lisp that seems to make a difference, but my point is that I don't know that any one of these behaviors is preferable over the others. Would your plan be to force conversion to bigfloats in place of any of these choices? >> >> Somewhat ambivalent... >> >> Jorge >> >> Richard Fateman <fateman@...<mailto:fateman@...>> writes: >> What about underflow? It seems to me it would be distressing if x^2 >> overflows to bigfloat >> but the mathematically equal quantity computed as 1/(1/x)^2 is a >> dividebyzero. >> >> Rupert Swarbrick <rswarbrick@...<mailto:rswarbrick@...>> writes: >> >> Hmm, good point. >> >> Although 1/(1/x) != x for floating x anyway: >> >> (%i46) block([a: 1/x], 1/a  x), x=0.123; >> (%o46)  1.387778780781446e17 >> >> (The nonsense with block() is to avoid the simplifier setting the >> expression to zero ahead of time.) >> >> Anyone got any ideas? Do we trap underflows at the moment? >> >> >> Rupert >> >> >>  >> Dr. Jorge Alberto Calvo >> Associate Professor of Mathematics >> Department of Mathematics and Physics >> Ave Maria University >> >> Phone: (239) 2801608 >> Email: jorge.calvo@...<mailto:jorge.calvo@...> >> Web: http://sites.google.com/site/jorgealbertocalvo >> >> >> >> >>  >> Managing the Performance of CloudBased Applications >> Take advantage of what the Cloud has to offer  Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Robert Dodier <robert.dodier@gm...>  20140219 19:13:39

On 20140219, Mark <zeitlinie@...> wrote: > Apart from the maxima manual, is there any other recommended howto > documentation for using rules and patterns in Maxima? No, but feel free to post any questions about rules & patterns to the mailing list. > I tried working with the 2nd eds. of Macsyma's user guide, but there are > differences between Macsyma and Maxima for me right away. E.g. if I > simply copycutandpaste the famous example to implement the factorial > using rules (pg. 220), then, tellsimpafter() is not applied recursively, > but only once. That sounds interesting, but as I don't have the Macsyma user guide at hand, I can't try out that example. Care to post the code in question? best Robert Dodier 
From: Rupert Swarbrick <rswarbrick@gm...>  20140219 19:00:19

Jorge Calvo <Jorge.Calvo@...> writes: > Hi there! > > I was doing a little exploration of underflow errors  mostly to > explain the IEEE754 standard to my students  and noticed that in > some cases, underflows are handled differently based on the underlying > platform. For instance, found that 4e324 (entered straight from the > prompt) rounds down to 0.0 in a Mac, up to 4.94065… x 10^324 in older > Windows machines, and is converted to the fixedpoint number 4.0d324 > in Linux and newer Windows machines. It's really the underlying Lisp > that seems to make a difference, but my point is that I don't know > that any one of these behaviors is preferable over the others. Would > your plan be to force conversion to bigfloats in place of any of these > choices? > > Somewhat ambivalent... > > Jorge I'm not entirely sure what I am in favour of either, so am hoping people with more experience will weigh in. But my initial thought was 1eLOTS => 0.0 is absolutely fine, whereas (%i56) (1e100)^4; (%o56) 0.0 is a bit more unfortunate. But I'm pretty unsure about how this would work in an ideal world and am hoping someone will chime in with a good idea! Rupert 
From: Thomas D. Dean <tomdean@wa...>  20140219 18:22:36

On 02/19/14 10:04, Ardillas del Monte wrote: > Btw, sorry if this question is an annoyance, but is there any way for > telling maxima to check which of the two solutions for 'x' is greater than > 'h'? I know it's the first of the two solutions, but... can maxima find > it? I tried to use assume(x>h) but it didn't change anything. The option of > adding a third equation as the inequation x>h isn't possible because > solve() doesn't support inequations AFAIK. > use to_poly_solve(). Tom Dean 
From: Ardillas del Monte <ardillasdelmonte@gm...>  20140219 18:04:31

> > On Wed, Feb 19, 2014 at 3:51 PM, Stavros Macrakis <macrakis@...>wrote: > >> The singularity at eta=1 is removable: >> >> etax: 1((1eta)*(h/x)); >> lambdax: 1((1lambda)*(h/x)); >> ec1: nu = lambdax*etax; >> ec2: e0 = (1lambdax)*(h/2); >> sols: solve([ec1,ec2],[x,e0]); >> >> limit(sols,eta,1) <<< shows that one solution with eta=1 is finite >> > Btw, sorry if this question is an annoyance, but is there any way for telling maxima to check which of the two solutions for 'x' is greater than 'h'? I know it's the first of the two solutions, but... can maxima find it? I tried to use assume(x>h) but it didn't change anything. The option of adding a third equation as the inequation x>h isn't possible because solve() doesn't support inequations AFAIK. ardi 
From: Ardillas del Monte <ardillasdelmonte@gm...>  20140219 17:08:31

On Wed, Feb 19, 2014 at 3:51 PM, Stavros Macrakis <macrakis@...>wrote: > The singularity at eta=1 is removable: > > etax: 1((1eta)*(h/x)); > lambdax: 1((1lambda)*(h/x)); > ec1: nu = lambdax*etax; > ec2: e0 = (1lambdax)*(h/2); > sols: solve([ec1,ec2],[x,e0]); > > limit(sols,eta,1) <<< shows that one solution with eta=1 is finite > True. Honestly, I thought I hit a bug, but I'm happy it isn't the case. Anyway, is there any configurable setting for telling maxima to extend the solutions in order to consider singularities? I mean, in this case, I'd expect to get different solutions depending on the value of eta. In theory I think it should be possible, because I tend to believe you don't arrive to such singularity unless you assume eta!=1 in the way. ardi 
From: Jorge Calvo <Jorge.C<alvo@av...>  20140219 16:22:56

Hi there! I was doing a little exploration of underflow errors  mostly to explain the IEEE754 standard to my students  and noticed that in some cases, underflows are handled differently based on the underlying platform. For instance, found that 4e324 (entered straight from the prompt) rounds down to 0.0 in a Mac, up to 4.94065… x 10^324 in older Windows machines, and is converted to the fixedpoint number 4.0d324 in Linux and newer Windows machines. It's really the underlying Lisp that seems to make a difference, but my point is that I don't know that any one of these behaviors is preferable over the others. Would your plan be to force conversion to bigfloats in place of any of these choices? Somewhat ambivalent... Jorge Richard Fateman <fateman@...<mailto:fateman@...>> writes: What about underflow? It seems to me it would be distressing if x^2 overflows to bigfloat but the mathematically equal quantity computed as 1/(1/x)^2 is a dividebyzero. Rupert Swarbrick <rswarbrick@...<mailto:rswarbrick@...>> writes: Hmm, good point. Although 1/(1/x) != x for floating x anyway: (%i46) block([a: 1/x], 1/a  x), x=0.123; (%o46)  1.387778780781446e17 (The nonsense with block() is to avoid the simplifier setting the expression to zero ahead of time.) Anyone got any ideas? Do we trap underflows at the moment? Rupert  Dr. Jorge Alberto Calvo Associate Professor of Mathematics Department of Mathematics and Physics Ave Maria University Phone: (239) 2801608 Email: jorge.calvo@...<mailto:jorge.calvo@...> Web: http://sites.google.com/site/jorgealbertocalvo 
From: 本田康晃 <yasuaki.honda@gm...>  20140219 15:46:50

Dear list, As I have not seen any additional comments, I have git push the changes to the master branch of the git source tree. I will separately add some test cases in rtest_tex.mac within couple of days. Thanks and best regards, Yasuaki Honda, Chiba, Japan 20140216 16:00 GMT+09:00 本田康晃 <yasuaki.honda@...>: > Dear Robert san, John san, > > I recently encountered a similar issue as originally pointed out by John > san. Before doing a fix, I searched and found this thread. > > My issue is a maxima error on performing gf_set_data(2,x^4+x+1). This > command returns a lisp defstruct object and causes the same error as > make_array(fixnum, 2) in imaxima or Maxima on Android. This error can be > reproducible on standard maxima with calling tex(gf_set_data(...)). > > I saw the latest source tree of maxima, but the patch proposed by John san > has not been applied. Also examining the proposed patch, I found the use > of verbquote wrong. It is designed to be used in combination with > texstring defined in imaxima.lisp. > > All considered, I have created a new patch. Basic policy is the same as > John san. For texatom() defined in mactex.lisp, If texatom(x) is given a > lisp object x, ($sconcat x) is performed to convert x to a string. Then I > give the string to texstring() for further processing if any. > > I also modified imaxima.lisp since there is no more need to redefine > texatom in imaxima.lisp. Things get much simpler and easier to maintain in > imaxima.lisp. > > If none oppose, I will apply the attached patch to the git source tree. > Also, I will add some test cases for tex() function giving lisp objects. > > I welcome any comments, as usual. > > Thanks and best regards, > Yasuaki Honda, Chiba, Japan > > > 20130925 1:04 GMT+09:00 John Lapeyre <lapeyre.math122a@...>: > > Hi, >> >> Here is a patch for tex(). It modifies src/mactex.lisp. >> I tested it by starting maxima 5.31.0, loading the modified >> source file, then running the entire testsuite. This is >> with sbcl/linux. >> >> There is a lot of room for improvement, but this is >> a good stopgap. >> >> I could not really see where to put an rtest. But this is >> what it does. >> >> (%i2) tex(make_array('fixnum,2)); >> $$"{Lisp Array: #(0 0)}"$$ >> >> instead of >> >> (%i1) tex(make_array('fixnum,2)); >> >> $$ >> Maxima encountered a Lisp error: >> >> The value #(0 0) is not of type SYMBOL. >> >> Automatically continuing. >> To enable the Lisp debugger set *debuggerhook* to nil. >> >> HTH, >> John >> >> >> On 09/22/2013 09:05 PM, Robert Dodier wrote: >> > On 20130922, John Lapeyre <lapeyre.math122a@...><lapeyre.math122a@...>wrote: >> > >> >> (%i1) tex(make_array(fixnum,2)); >> >> $$ >> >> Maxima encountered a Lisp error: >> >> >> >> The value #(0 0) is not of type SYMBOL. >> > >> > OK, well, that's a bug. We can certainly do better. >> > >> >> One solution is to change texatom in src/mactex.lisp >> >> and add a function from imaxima.lisp (which may have been >> >> borrowed from somewhere else.): >> > >> > Can you present the proposed solution as a diff with respect to the >> > version which was used to build whatever binary you are executing? >> > It will help others understand exactly what is being changed. >> > >> > If you are working with Git, then git diff shows the change. If you are >> > modifying some source code and reloading it or something like that, then >> > keep the original in some file and use commandline diff as: >> > >> > diff u foo.lisp foo.lisporiginal >> > >> > or whatever. 'diff' is usually present in Unixlike systems. If you are >> > working on MS Windows, you can get 'diff' as part of Cygwin or MinGW. >> > Nota bene: My experience with Cygwin has been pretty painful as it tries >> > to redefine a bunch of stuff to make your Windows environment Unixlike, >> > which inevitably fails, leading to a randomly messed up environment. >> > I don't really have a recommendation, except to switch to something >> other >> > than Windows if you can. As ever, YMMV. >> > >> > best >> > >> > Robert Dodier >> > >> > _______________________________________________ >> > Maxima mailing list >> > Maxima@... >> > http://www.math.utexas.edu/mailman/listinfo/maxima >> >> >> >> _______________________________________________ >> Maxima mailing list >> Maxima@... >> http://www.math.utexas.edu/mailman/listinfo/maxima >> >> > 
From: Stavros Macrakis <macrakis@al...>  20140219 14:51:55

The singularity at eta=1 is removable: etax: 1((1eta)*(h/x)); lambdax: 1((1lambda)*(h/x)); ec1: nu = lambdax*etax; ec2: e0 = (1lambdax)*(h/2); sols: solve([ec1,ec2],[x,e0]); limit(sols,eta,1) <<< shows that one solution with eta=1 is finite On Wed, Feb 19, 2014 at 9:15 AM, Ardillas del Monte < ardillasdelmonte@...> wrote: > etax: 1((1eta)*(h/x)); > lambdax: 1((1lambda)*(h/x)); > ec1: nu = lambdax*etax; > ec2: e0 = (1lambdax)*(h/2); > solve([ec1,ec2],[x,e0]); > 
From: Ardillas del Monte <ardillasdelmonte@gm...>  20140219 14:15:37

Hi, I don't understand this. If I do the following: etax: 1((1eta)*(h/x)); lambdax: 1((1lambda)*(h/x)); ec1: nu = lambdax*etax; ec2: e0 = (1lambdax)*(h/2); solve([ec1,ec2],[x,e0]); I get two solutions for e0, both with 4eta4 in the denominator, which isn't a legal solution because, in fact, eta will be in the range [ 0.5 , 1 ], and so both e0 solutions become division by zero for eta=1. If I force eta=1, like this: etax: 1((1eta)*(h/x)),eta=1; lambdax: 1((1lambda)*(h/x)); ec1: nu = lambdax*etax; ec2: e0 = (1lambdax)*(h/2); solve([ec1,ec2],[x,e0]); The solution for e0 is then valid for eta=1: e0=(h*nuh)/2 Why is maxima giving me a nonvalid solution for eta=1 if I leave eta undefined? Thanks a lot in advance, ardi 
From: Rupert Swarbrick <rswarbrick@gm...>  20140219 08:30:25

Richard Fateman <fateman@...> writes: > What about underflow? It seems to me it would be distressing if x^2 > overflows to bigfloat > but the mathematically equal quantity computed as 1/(1/x)^2 is a > dividebyzero. Hmm, good point. Although 1/(1/x) != x for floating x anyway: (%i46) block([a: 1/x], 1/a  x), x=0.123; (%o46)  1.387778780781446e17 (The nonsense with block() is to avoid the simplifier setting the expression to zero ahead of time.) Anyone got any ideas? Do we trap underflows at the moment? Rupert 
From: Mark <zeitlinie@ya...>  20140219 08:22:51

Apart from the maxima manual, is there any other recommended howto documentation for using rules and patterns in Maxima? I tried working with the 2nd eds. of Macsyma's user guide, but there are differences between Macsyma and Maxima for me right away. E.g. if I simply copycutandpaste the famous example to implement the factorial using rules (pg. 220), then, tellsimpafter() is not applied recursively, but only once. M 
From: Robert Dodier <robert.dodier@gm...>  20140219 02:17:30

On 20140128, Edward Montague <quintin9g@...> wrote: > Amongst other projects , I'm looking at painsys.max ; for > maxima usage . > > I've located one possible portion of code that's > causing some problems for maxima. What version of the code are you working with, and what are the problems? I think it would be interesting to get Willy Hereman's code working with Maxima. best, Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140219 00:45:56

On 20140127, Jorge Barros de Abreu <ficmatin10@...> wrote: > Is it correct or needs a point??? > > @code{A} where @code{A} is an atom declared to be an evaluation flag**.** > @mref{evflag} causes @code{A} to be bound to @code{true} during the > evaluation of @var{expr}. No, it doesn't need it. The English version could be clarified as follows: @code{A} where @code{A} is an atom declared to be an evaluation flag (see @mref{evflag}) causes @code{A} .... best, Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140219 00:11:59

On 20140218, Marcus Menzel <flareload@...> wrote: > the parameters found by qtiplot look like: > ),R_0=167.7259522040793,B=3138.526530316507,T_0=235.9190563256873 Try including tol=<some small number> e.g., tol=1e8, in the arguments for lsquares_estimates. By default the numerical minimization gives up pretty easily (default tol=1e4 if I remember correctly). Maybe it's helpful to look at the mean square error here. mse : lsquares_mse (mtx, [x, y], y=R_0*%e^(B*((1/(x+273))(1/T_0)))); => ('sum(('mtx[i,2]R_0*%e^(B*(1/('mtx[i,1]+273)1/T_0)))^2,i,1,22))/22 For the qtiplot parameters, mse, R_0=167.7259522040793,B=3138.526530316507,T_0=235.9190563256873, nouns; => .1731740324270996 For parameters found by lsquares_estimates with tol=1e8, mse, R_0 = 187.9140497158917, B = 3138.888078754682, T_0 = 233.8987927544742, nouns; => .1686344374889145 But with the default value of tol, mse, R_0 = 192.7060692796723, B = 2000.672696405146, T_0 = 228.268462434801, nouns; => 180.8454930515481 best Robert Dodier 