From: Robert Dodier <robert.dodier@gm...>  20100806 15:54:30

On Fri, Aug 6, 2010 at 9:47 AM, Richard Fateman <fateman@...> wrote: > This standard is adhered to by apparently all the correctly > compliant common lisps. > > Which apparently does not include ECL/Sparc. > So it is a bug in ECL/Sparc. So you can go fix it since it is open source. Oh, cut it out. Did you look at the Maxima code and the relevant bit of the CFLHS ? I didn't think so. Robert Dodier 
From: Dr. David Kirkby <david.kirkby@on...>  20100806 00:33:30

asinh(1.0) is approximately 0.88137358701954302523. Using ECL 10.2.1 and Maxima 5.20.1, on two Solaris 10 systems, we get a problem on the system running Solaris x86, but not on the system with the SPARC processor. This was in Sage 4.5.2.rc1, but Maxima is (as far as I can tell), run independently of Sage, so the maxima input and output are seen, with no processing by Sage. On the Solaris 10 x86 system, we see: ============================================================ drkirkby@...:[/home/palmieri/fulvia/32bit/sage4.5.2.rc1] $ ./sage maxima ;;; Loading #P"/home/palmieri/fulvia/32bit/sage4.5.2.rc1/local/lib/ecl/defsystem.fas" ;;; Loading #P"/home/palmieri/fulvia/32bit/sage4.5.2.rc1/local/lib/ecl/cmp.fas" ;;; Loading #P"/home/palmieri/fulvia/32bit/sage4.5.2.rc1/local/lib/ecl/sysfun.lsp" Maxima 5.20.1 http://maxima.sourceforge.net using Lisp ECL 10.2.1 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) asinh(1.0); (%o1) .8813735870195429 (%i2) =============================================================== Although the result is numerically correct, it is certainly not printed in a very nice way. When run on a Solaris 10 SPARC system, one gets a leading zero as one would hope for. ================================================================ 32 drkirkby@...:[~/redstart/32/sage4.5.2.rc1] $ ./sage maxima ;;; Loading #P"/export/home/drkirkby/redstart/32/sage4.5.2.rc1/local/lib/ecl/defsystem.fas" ;;; Loading #P"/export/home/drkirkby/redstart/32/sage4.5.2.rc1/local/lib/ecl/cmp.fas" ;;; Loading #P"/export/home/drkirkby/redstart/32/sage4.5.2.rc1/local/lib/ecl/sysfun.lsp" Maxima 5.20.1 http://maxima.sourceforge.net using Lisp ECL 10.2.1 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) asinh(1.0); (%o1) 0.881373587019543 (%i2) ================================================================ Can anyone suggest what may or may not be the cause of this difference in behavior? There's a bit more details on a Sage trac bug ticket I created for this, though I believe there's enough information above. Although the Solaris 10 SPARC port of Sage has been stable for several month, on Solaris 10 x86, Sage was built for the first time this week, so a few problems do exist, though I don't think there's anything related to this problem. Dave 
From: Dr. David Kirkby <david.kirkby@on...>  20100806 00:21:51

On 08/ 6/10 12:58 AM, Dr. David Kirkby wrote: > Can anyone suggest what may or may not be the cause of this difference > in behavior? There's a bit more details on a Sage trac bug ticket I > created for this, though I believe there's enough information above. > Sorry, I forgot to put the trac ticket http://trac.sagemath.org/sage_trac/ticket/9693 which shows the missing leading zero when computing asinh(1.0) on a Solaris 10 x86 system, but with it correctly formatted on a Solaris 10 SPARC system. It's also correctly formatted on Linux and OS X systems  the lack of a leading zero seems unique to Solaris x86 Dave 
From: Robert Dodier <robert.dodier@gm...>  20100806 05:59:52

On 8/5/10, Dr. David Kirkby <david.kirkby@...> wrote: > (%i1) asinh(1.0); > (%o1) .8813735870195429 Appears to be a consequence of the way ECL formats floating point numbers. I can produce an example on Linux so it's not specific to Solaris. e.g. (format nil "~vf" 17 (/ 1d0 1.39239992382181823812d0)) => ".7181844690534236" By default Maxima calls (format nil "~vf" 17 x) where x is the number to be formatted. It appears that sometimes the leading 0 is omitted in order to squeeze x into 17 characters. I think ECL's behavior is reasonable. It seems likely that the we could make the 0 reappear by giving at least one more character in the field width (circa line 339 in EXPLODEN in maxima/src/commac.lisp) ... be that as it may, I'm not inclined to do it; the number formatting stuff has been thrashed a lot over the years and I'm not convinced this is a change of lasting importance. Maybe someone wants to talk me into it. A workaround might be to set the Maxima global variable maxfpprintprec to something greater than 16 (the default). Does that help? FWIW Robert Dodier 
From: Dr. David Kirkby <david.kirkby@on...>  20100806 14:57:29

On 08/ 6/10 06:59 AM, Robert Dodier wrote: > On 8/5/10, Dr. David Kirkby<david.kirkby@...> wrote: > >> (%i1) asinh(1.0); >> (%o1) .8813735870195429 > > Appears to be a consequence of the way ECL formats > floating point numbers. I can produce an example on Linux > so it's not specific to Solaris. e.g. > > (format nil "~vf" 17 (/ 1d0 1.39239992382181823812d0)) > => ".7181844690534236" > By default Maxima calls (format nil "~vf" 17 x) where x > is the number to be formatted. It appears that sometimes > the leading 0 is omitted in order to squeeze x into 17 characters. > > I think ECL's behavior is reasonable. It seems likely that the > we could make the 0 reappear by giving at least one more > character in the field width (circa line 339 in EXPLODEN in > maxima/src/commac.lisp) ... be that as it may, I'm not > inclined to do it; the number formatting stuff has been thrashed > a lot over the years and I'm not convinced this is a change > of lasting importance. Maybe someone wants to talk me into it. Well to me at least, it is not normal behaviour for software to print a number as .8813735870195429, but rather more usual to print it as 0.8813735870195429. I would personally consider printing .8813735870195429 irrespective if was Maxima, Mathematica or on a pocket calculator. Since similar behavior can be produced with CMUCL and clisp on Linux (see examples Raymond Toy posted) and you concede ECL's behavior is reasonable, I would have thought changing it in Maxima would have been sensible. I can't see why this fix would not be of lasting importance. > A workaround might be to set the Maxima global variable > maxfpprintprec to something greater than 16 (the default). > Does that help? I'm not keen on that. A doubleprecision number in IEE754 format has 53bits in the significand, so the precision is In[23]:= Log[10,2^53] //N Out[23]= 15.9546 decimal digits. In that case, printing 16 digits (Maxima's default) seems reasonable, but printing 17 digits does not. Printing a leading zero makes sense to me  printing digits unlikely to be correct does not. As a second point, failing to print the leading zero is an inconstancy, as sometimes it's printed. > FWIW > > Robert Dodier > Anyway, that's my best attempt to convince you! Dave 
From: Raymond Toy <toy.raymond@gm...>  20100808 19:32:08

On 8/6/10 10:56 AM, Dr. David Kirkby wrote: > A workaround might be to set the Maxima global variable >> maxfpprintprec to something greater than 16 (the default). >> Does that help? > > I'm not keen on that. A doubleprecision number in IEE754 format has > 53bits in the significand, so the precision is > > In[23]:= Log[10,2^53] //N > > Out[23]= 15.9546 > > decimal digits. > > In that case, printing 16 digits (Maxima's default) seems reasonable, > but printing 17 digits does not. Since the floatingpoint number base is 2 and not 10, there are issues to be solved when converting from one to the other. From the examples, it is pretty clear that 16 digits is NOT always enough to convert the base 2 number to base 10 if you want the result to be the nearest base 10 number closes to the floatingpoint base 2 number. > > Printing a leading zero makes sense to me  printing digits unlikely > to be correct does not. Why is printing a nonsignificant leading zero more important than printing the number correctly to the last digit? I'd much rather see the last correct digit than the irrelevant leading 0. > > As a second point, failing to print the leading zero is an > inconstancy, as sometimes it's printed. Yes, it is inconsistent on the assumption that it should be printed. It's not inconsistent if the criterion is to print out as many digits as needed to represent the number as accurately as possible given the constraint that the result takes 17 characters. Ray 
From: Dr. David Kirkby <david.kirkby@on...>  20100806 15:16:56

On 08/ 6/10 10:04 AM, Raymond Toy wrote: > On 8/6/10 1:59 AM, Robert Dodier wrote: >> On 8/5/10, Dr. David Kirkby<david.kirkby@...> wrote: >> >>> (%i1) asinh(1.0); >>> (%o1) .8813735870195429 >> Appears to be a consequence of the way ECL formats >> floating point numbers. I can produce an example on Linux >> so it's not specific to Solaris. e.g. >> >> (format nil "~vf" 17 (/ 1d0 1.39239992382181823812d0)) >> => ".7181844690534236" > Nice example. It's not even specific to ecl. CMUCL and clisp print the > same thing. > > The difference between ecl on Solaris/sparc and Solaris/x86 could very > well be the floatingpoint units or the routines used to compute cl:asinh. > > (format nil "~vf" 17 (asinh 1d0)) > > produces a leading 0 on Solaris with cmucl, but there's no leading zero > on Solaris clisp. The number value of (asinh 1d0) is slightly different > too. > > Ray It's worth noting however that the failure to print the leading zero is seen on a common CPU (Intel Xeon), albient with a less common operating system (Solaris). The strange thing, when Solaris is run on the SPARC processor, the output is similar to Intel systems on AMD/Intel CPUs. Small differences are to be expected when computing these things, especially on SPARC processors, so I'm not concerned about the exact value of the last digit  that's pretty irrelevant. Dave 
From: Robert Dodier <robert.dodier@gm...>  20100806 15:54:30

On Fri, Aug 6, 2010 at 9:47 AM, Richard Fateman <fateman@...> wrote: > This standard is adhered to by apparently all the correctly > compliant common lisps. > > Which apparently does not include ECL/Sparc. > So it is a bug in ECL/Sparc. So you can go fix it since it is open source. Oh, cut it out. Did you look at the Maxima code and the relevant bit of the CFLHS ? I didn't think so. Robert Dodier 
From: Juan Jose GarciaRipoll <juanjose.garciaripoll@go...>  20100808 10:56:04

Sorry for the lack of feedback. I am currently on holidays with no computer and no stable internet access. I will look into this issue when I come back, but just for the record, ECL's implementation of FORMAT is that of CMUCL's with some minor changes to fit it in  at some points we may rely on the C library for printing, but this is not done in FORMAT AFAIR Juanjo On Fri, Aug 6, 2010 at 5:54 PM, Robert Dodier <robert.dodier@...> wrote: > On Fri, Aug 6, 2010 at 9:47 AM, Richard Fateman <fateman@...> wrote: > >> This standard is adhered to by apparently all the correctly >> compliant common lisps. >> >> Which apparently does not include ECL/Sparc. >> So it is a bug in ECL/Sparc. So you can go fix it since it is open source. > > Oh, cut it out. Did you look at the Maxima code and the relevant > bit of the CFLHS ? I didn't think so. > > Robert Dodier > >  > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIMdev2dev > _______________________________________________ > Eclslist mailing list > Eclslist@... > https://lists.sourceforge.net/lists/listinfo/eclslist >  Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com 