zero

[marcW]

hi,
I'm new at this, some experience with mathematica.
I spent the better part of 2 days trying to find out why
f= a*x
g=f.subs({a:0.6}]
show(g)

produces so many zeroes.lol. It's laughable.
I've never seen something like this.
It shouldn't be complicated to get rid of these zeros right?

[Jason Grout]

It's to show the true precision of the number. 0.6 is a 53-bit
precision number, so the zeroes indicate that.

Note the difference between a 10-bit precision number and a 100-bit
precision number:

sage: RealField(100)(0.6)
0.60000000000000000000000000000
sage: RealField(10)(0.6)
0.60

Maybe there should be an option to not show the precision using the
zeroes? In general, I think showing the precision is a good idea.

Thanks,

Jason


--
Jason Grout

[ma...@mendelu.cz]

fixed in http://trac.sagemath.org/sage_trac/ticket/7356

[marcW]

thank you,
precision is one thing, but the output gets messy, and the common
assumption that trailing zeros are redundant works fine for me.
I was trying this for a start (but then I stopped in my tracks)

Coef =var('a, b, alpha_A, alpha_B, beta_A, beta_B, k_A, k_B, J, R_A,
R_B')
values ={a: 15,b: 0.006,alpha_A: 3,beta_A:4.8,beta_B:4.8,k_A:0.7,k_B:
0.375}
f1 = beta_A/2 * J^2*(1/(b+beta_A*R_A+beta_B*R_B)^2+6*b/(2*b
+3*beta_A*R_A+3*beta_B*R_B)^3)==2*k_A/R_A^2;
f2 = beta_B/2 * J^2*(1/(b+beta_A*R_A+beta_B*R_B)^2-6*b/(2*b
+3*beta_A*R_A+3*beta_B*R_B)^3)==2*k_B/R_B^2;
show(f1)
show(f2)
f1v=f1.subs(J=a-alpha_A-alpha_B).subs(values)
show(f1v)

[marcW]

very sorry, I ran into this, but I have no clue what to do to with it,
as I said I am new to all this.
thank you


On 11 dec, 19:36, "ma...@mendelu.cz" <ma...@mendelu.cz> wrote:
> fixed inhttp://trac.sagemath.org/sage_trac/ticket/7356

[Jason Grout]

ma...@mendelu.cz wrote:
> fixed in http://trac.sagemath.org/sage_trac/ticket/7356
>

but it is only for latex(expr), right? I thought the poster was asking
about generic printing.

Jason




--
Jason Grout

[Jason Grout]

marcW wrote:
> thank you,
> precision is one thing, but the output gets messy, and the common
> assumption that trailing zeros are redundant works fine for me.
> I was trying this for a start (but then I stopped in my tracks)

You're right that the output gets messy, especially if you don't care
that much about trailing zeros.

So how do we accommodate both crowds---the one that wants to explicitly
see the precision, and the others that just want nice-printing numbers,
regardless of how many zeros the computer actually knows exist?

Jason


--
Jason Grout

[marcW]

hi, i wouldn't know, all I know is that C, Mathematica, php whatever I
used in my life, i never ran into this.
sure, it's about formatted output (the distinction between generic
output and latex(expr) escapes me: I just look at the notebook).
A filter which processes the result to be printed and trims to a
desired (printing) precision maybe? would suit everybody I guess.
It's not even about zeros: all i need is two digits after the dot,
exceptionally 3 (yes, it's economics, a 2 digit science)
thanks again
m

[Jason Grout]

marcW wrote:
> hi, i wouldn't know, all I know is that C, Mathematica, php whatever I
> used in my life, i never ran into this.
> sure, it's about formatted output (the distinction between generic
> output and latex(expr) escapes me: I just look at the notebook).
> A filter which processes the result to be printed and trims to a
> desired (printing) precision maybe? would suit everybody I guess.
> It's not even about zeros: all i need is two digits after the dot,
> exceptionally 3 (yes, it's economics, a 2 digit science)
> thanks again

If you don't care about precision (i.e., all numbers are rounded off to
2-3 digits), then you can declare your numbers this way:


sage: R=RealField(15)
sage: R(pi)
3.142
sage: R(0.6)
0.6000
sage: R(4.8)
4.800


In other words, you're explicitly saying that the precision on the
numbers is 15 bits (not 53 bits, like usual).

sage: Coef =var('a, b, alpha_A, alpha_B, beta_A, beta_B, k_A, k_B, J,
R_A,R_B')
sage: R=RealField(15)
sage: values ={a: R(15),b: R(0.006),alpha_A:
R(3),beta_A:R(4.8),beta_B:R(4.8),k_A:R(0.7),k_B:R(0.375)}
sage: f1 = beta_A/2 *
J^2*(1/(b+beta_A*R_A+beta_B*R_B)^2+6*b/(2*b+3*beta_A*R_A+3*beta_B*R_B)^3)==2*k_A/R_A^2;
sage: f2 = beta_B/2 *
J^2*(1/(b+beta_A*R_A+beta_B*R_B)^2-6*b/(2*b+3*beta_A*R_A+3*beta_B*R_B)^3)==2*k_B/R_B^2;
sage: f1
1/2*(1/(R_A*beta_A + R_B*beta_B + b)^2 + 6*b/(3*R_A*beta_A +
3*R_B*beta_B + 2*b)^3)*J^2*beta_A == 2*k_A/R_A^2
sage: f2
1/2*(1/(R_A*beta_A + R_B*beta_B + b)^2 - 6*b/(3*R_A*beta_A +
3*R_B*beta_B + 2*b)^3)*J^2*beta_B == 2*k_B/R_B^2
sage: f1v=f1.subs(J=a-alpha_A-alpha_B).subs(values)
sage: f1v
2.400*(alpha_B - 12.00)^2*(1/(4.800*R_A + 4.800*R_B + 0.006000)^2 +
0.03600/(14.40*R_A + 14.40*R_B + 0.01200)^3) == 1.400/R_A^2
sage:


Jason



--
Jason Grout

[Simon King]

Hi Marc!

On 12 Dez., 15:48, Jason Grout <jason-s...@creativetrax.com> wrote:
> marcW wrote:

[...]

> If you don't care about precision (i.e., all numbers are rounded off to
> 2-3 digits), then you can declare your numbers this way:
>
> sage: R=RealField(15)
> sage: R(pi)

[...]

Or, if you *do* care about the precision in the computation, but don't
want to see more then 3 digits in the final result, you may do
sage: print 1.0
1.00000000000000
sage: print '%.3f'%1.0
1.000

I.e., convert the numbers in a formatted string.

Cheers,
Simon

[Jason Grout]

Simon King wrote:
> Hi Marc!
>
> On 12 Dez., 15:48, Jason Grout <jason-s...@creativetrax.com> wrote:
>> marcW wrote:
> [...]
>> If you don't care about precision (i.e., all numbers are rounded off to
>> 2-3 digits), then you can declare your numbers this way:
>>
>> sage: R=RealField(15)
>> sage: R(pi)
> [...]
>
> Or, if you *do* care about the precision in the computation, but don't
> want to see more then 3 digits in the final result, you may do
> sage: print 1.0
> 1.00000000000000
> sage: print '%.3f'%1.0
> 1.000

Hmmm. Yeah, we probably ought to make this easier to just print the
first n digits after the decimal by default for RR numbers, or to not
print out the trailing zeros. I can't imagine telling my students, for
example, that they need to do '%.3f'%num every time they come across a
number, especially since they just want to display the equation, not
format it as a string.

What do people think about this interface?

sage: RR.print_digits=3
sage: 3.09384
3.094
sage: RR.print_trailing_zeros=False
sage: RR.print_digits=None
sage: 3.09384
3.09384

Make it something like the RR.scientific_notation flag that is currently
in use.

[marcW]

hi,
I'm really surprised about the consideration for a remark like a
newbie like me.
Of course computational precision is important, the little game i was
showing leads to a soluion
around 0.00001 for ra and rb.
So that brings us to part 2: convert to string; works for an isolated
number, but not for mixtures of symbolic and numeric expressions I
would think.
Can the latex (or generic) output expression be parsed for pretty
printing (his means find the numbers in the expression and put them
through %f% ?
thanks
m

[Jason Grout]

marcW wrote:
> hi,
> I'm really surprised about the consideration for a remark like a
> newbie like me.

Well, we definitely like to listen to people who give suggestions!

> Of course computational precision is important, the little game i was
> showing leads to a soluion
> around 0.00001 for ra and rb.
> So that brings us to part 2: convert to string; works for an isolated
> number, but not for mixtures of symbolic and numeric expressions I
> would think.
> Can the latex (or generic) output expression be parsed for pretty
> printing (his means find the numbers in the expression and put them
> through %f% ?

I've opened up an enhancement ticket here:

http://trac.sagemath.org/sage_trac/ticket/7682

I also noticed that the introduction of all these numbers occurred at
the pynac switch. In http://trac.sagemath.org/sage_trac/ticket/4572, we
see a patch which made the old symbolic system not print so many zeros,
with the comment "In addition, this has the benefit of removing the
trailing zeros in calculus expressions involving real numbers (as they
didn't really contain any information)."

Thanks,

Jason