[Aimmath-developers] [ aimmath-Bugs-823941 ] bug in latex/latex/float
Brought to you by:
gustav_delius,
npstrick
From: SourceForge.net <no...@so...> - 2003-10-15 15:02:00
|
Bugs item #823941, was opened at 2003-10-15 03:33 Message generated for change (Comment added) made by monks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=439479&aid=823941&group_id=44411 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gustav W Delius (gustav_delius) Assigned to: Nobody/Anonymous (nobody) Summary: bug in latex/latex/float Initial Comment: There is a bug in latex/latex/float exemplified by the following question: name> test h> Digits=14 t> type in $1.0123456789012$ s> [ans->`aim/TestNumeric` (ans,1.0123456789012,`sf`=14),1.0123456789012] end> This will print that the teacher's answer was 1.1 ---------------------------------------------------------------------- >Comment By: Ken Monks (monks) Date: 2003-10-15 11:01 Message: Logged In: YES user_id=766386 I fixed this bug and posted the changes to aim/LaTeX.mpl to CVS. ---------------------------------------------------------------------- Comment By: Greg Gamble (gregg0) Date: 2003-10-15 05:42 Message: Logged In: YES user_id=766524 Of course, you meant h> Digits := 14 Anyway, after starting up Maple and reading Console.mpl, I've tried the sequence: Digits := 14; latex(1.0123456789012); and confirm your findings with the current development version of AIM. However, with an earlier AIM I still have running, the correct value is given. So the bug is in the AIM 3 overriding definition of `latex/latex/float`. The reason you only get the one decimal place is because there is another AIM-defined variable LaTeXDigits which is by default 3 (maybe there ought to be two decimal places? ... is the decimal point counted as a digit?). As to why you get 1.1 and not 1.0, the clue is in that the function splits off the integer part. What's left starts with a 0 and Maple takes the number 0123 to be the same as 123. The function hasn't taken that into account and only works correctly when the first decimal place is non-zero. I'll see if I can put together a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=439479&aid=823941&group_id=44411 |