Thanks a lot for that and thanks to Michael for reviewing it!
Stan
On Nov 25, 12:30 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> The issues were all doctests failing in random other files that use
> calculus because the way things printed changed. I've fixed them all
> and posted another
On Nov 25, 3:30 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
Hi,
> The issues were all doctests failing in random other files that use
> calculus because the way things printed changed. I've fixed them all
> and posted another patch, so please feel free to get an account and
> review.
T
The issues were all doctests failing in random other files that use
calculus because the way things printed changed. I've fixed them all
and posted another patch, so please feel free to get an account and
review. (Basically, one looks at the code, applies the patches, and
makes sure everyt
I was going to ask for a Trac login and find out how to review
patches, but I just noticed that more qualified people than me have
taken care of it - and encountered other problems. Pity. Thanks a lot
for pushing it a bit further!
Stan
On Nov 20, 11:03 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wro
> > Thanks a lot for that, Robert!
>
> Seehttp://trac.sagemath.org/sage_trac/ticket/4572
Thanks to you from here too! This relieves yet another of the okay-
but-still-annoying things I've experienced in Sage. I can't import
the whole patch from here but just making the actual code change
worked
On Nov 20, 2008, at 1:54 AM, Stan Schymanski wrote:
> Thanks a lot for that, Robert!
See http://trac.sagemath.org/sage_trac/ticket/4572 Do you want to
review it?
> Is the ultimate "fix" the one that will
> use pynac instead of maxima? I can't wait for this one.
Yep, though we won't be replac
Thanks a lot for that, Robert! Is the ultimate "fix" the one that will
use pynac instead of maxima? I can't wait for this one.
All the best,
Stan
On Nov 19, 6:46 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Nov 18, 2008, at 11:18 PM, Stan Schymanski wrote:
>
> > Hi Robert,
>
> > Will the
On Nov 18, 2008, at 11:18 PM, Stan Schymanski wrote:
> Hi Robert,
>
> Will the fix of the interaction with Maxima allow conservation of
> precision of arguments passed through Maxima? This would satisfy my
> needs.
Actually, the "fix" is avoiding Maxima for everything symbolic.
> Depending on h
Hi Robert,
Will the fix of the interaction with Maxima allow conservation of
precision of arguments passed through Maxima? This would satisfy my
needs. Depending on how long this is going to take, I would like Mike's
interim fix to be implemented. It doesn't make anything worse compared
with
On Nov 18, 2008, at 5:57 AM, Stan Schymanski wrote:
>
> Ah, I see:
>
> dummy1 = RealField(8)(0.1);dummy1
> 0.10
>
> dummy2 = RealField(16)(0.1);dummy2
> 0.1000
>
> latex(x*dummy1)
> {0.1001 x}
>
> latex(x*dummy2)
> {0.1 x}
>
> This is not quite what one would expect. However, the behaviour before
Ah, I see:
dummy1 = RealField(8)(0.1);dummy1
0.10
dummy2 = RealField(16)(0.1);dummy2
0.1000
latex(x*dummy1)
{0.1001 x}
latex(x*dummy2)
{0.1 x}
This is not quite what one would expect. However, the behaviour before
the fix was not much better in my opinion, as the precision was not
obvious fro
Hi Robert,
In my understanding the changes only affect the latex display, not for
example the print command:
dummy = 0.60001;dummy
0.6000100
latex(dummy)
0.60001
print(dummy)
0.6000100
What do you mean by real numbers of different precisions being printed
the same?
dummy = Re
The side effect is that now real numbers of different precisions all
print the same, so I'm not sure that this would be considered a "fix"
as the trailing zeros are intentional. There should be print modes
that one can set (globally, on the ring, or with contexts).
- Robert
On Nov 17, 2008
Hi Mike,
This is great, it does exactly what I wanted. Thanks a lot! Are there
any potentially undesired side-effects of the changes in real_mpfr.pyx
or could this fix be included in future versions of sage?
Stan
On Nov 18, 8:14 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Mon,
Hi Robert,
Thanks, this explains what is going on. Would there be a way of
including the regular expressions procedure in the show() command? The
output of the line you proposed is a string, which doesn't show well
in show(). :)
Thanks again,
Stan
On Nov 17, 8:05 pm, Robert Bradshaw <[EMAIL PRO
Hello,
On Mon, Nov 17, 2008 at 11:11 PM, Stan Schymanski <[EMAIL PROTECTED]> wrote:
>
> Dear Mike,
>
> Thanks a lot for that, this looks very promising. However, after
> making the suggested change, the behaviour of latex() did not change.
> Do I need to restart sage for the changes to take effec
Dear Mike,
Thanks a lot for that, this looks very promising. However, after
making the suggested change, the behaviour of latex() did not change.
Do I need to restart sage for the changes to take effect?
dummy._latex_?? reflects the changes made, but the 0s are still there
when I latex(dummy).
d
Its probably not necessary to note this, but on the slim chance it is
I'll point out that the regular expression module, re, is a standard
python module that is not imported by default so you have to do
sage: import re
before Robert's solution.
-mh
On Nov 17, 1:05 pm, Robert Bradshaw <[EMAIL P
Any decimal number that goes into maxima turns into a 53-bit floating
point number (at least by default), which then turns into a 53 bit
MPFR coming out. The reason all the trailing 0's are exposed is to
show how much precision is known. Maxima (as far as I know) doesn't
have the concept o
Dear Marshall,
Thanks a lot for looking into this. I tried similar approaches as well,
and so did the original poster. However, as soon as you introduce a
symbolic variable into the equation, latex does weird things such as:
latex(RealField(8)(0.6)*x)
produces
"{0.6016000 x}"
Does thi
Marshall Hampton wrote:
> There are a number of interact examples on the wiki (such as the Gram-
> Schmidt one at http://wiki.sagemath.org/interact/linear_algebra) that
> work around this problem by casting to a field of low precision, for
> example doing something like
>
> latex(RealField(8)(0.6
If a is your real number, and then a._latex_?? will point you in the
direction that you need to go. It leads to the _latex_ function for
which there really isn't anything deep going on.
If all you care about is truncating zeros, then following changes will do:
diff -r 07a824fa8f2b sage/rings/re
On Mon, Nov 17, 2008 at 7:12 AM, Marshall Hampton <[EMAIL PROTECTED]> wrote:
>
> There are a number of interact examples on the wiki (such as the Gram-
> Schmidt one at http://wiki.sagemath.org/interact/linear_algebra) that
> work around this problem by casting to a field of low precision, for
> e
There are a number of interact examples on the wiki (such as the Gram-
Schmidt one at http://wiki.sagemath.org/interact/linear_algebra) that
work around this problem by casting to a field of low precision, for
example doing something like
latex(RealField(8)(0.6))
produces "0.60".
Hope that help
A week older and still not smarter...
Sorry for the noise, but I am still trying to find a way of getting
useful latex output for equations that contain decimal numbers. It
seems that the previous posts passed below the radars of those that
might know the answer, so I am trying to push it to the s
It seems that latex(eqn) just evaluates eqn and prints the result in
latex notation, without cutting off annoying 0s or giving the user the
opportunity to set a precision. I find this very annoying, as such
latex output is not very useful for illustration purposes. Does anyone
know a trick how to
26 matches
Mail list logo
