jaydfox's profile - activity

I haven't had that specific problem (yet), but I've run into issues restoring data in complex class types, especially within my own classes. If I modify my class, I will get an error when trying to restore the saved data, even if none of the data structures changed. I've gotten in the habit of saving large amounts of data in very bland data types. For example, I have a class which contains a matrix and multiple lists of matrices, as well as lists of lists of vectors. I ended up writing my own save and load procedures, which save out the individual matrices and lists to filenames that are based on the class variable names. Perhaps it's possible for you to re-export the data from sage 8.9 in a more basic format, then import in 9.x. Just a guess.

Hey, thanks for the link on ARB. I've started reading about it, and I'm totally geeking out!

Below is what I was able to come up with. I checked the first couple iterations to make sure they were correct. After that, it looks right at a glance, but I haven't verified. This is from my old SAGE 8.4 installation (I have 9.0 on a different computer), so the print statement will be formatted differently in version 9.0.

The key is to substitute the result back into v0 before substituting back into vk.

sage: v0 = log(k)
sage: for n in range(5):
....:     vk = log(k-k1) + beta*v0(k=k1)
....:     FOC = vk.diff(k1)
....:     k1star = solve(FOC==0, k1)
....:     print(n, k1star)
....:     v0 = (vk).subs(k1=k1star[0].rhs())
....:
(0, [k1 == beta*k/(beta + 1)])
(1, [k1 == (beta^2 + beta)*k/(beta^2 + beta + 1)])
(2, [k1 == (beta^3 + beta^2 + beta)*k/(beta^3 + beta^2 + beta + 1)])
(3, [k1 == (beta^4 + beta^3 + beta^2 + beta)*k/(beta^4 + beta^3 + beta^2 + beta + 1)])
(4, [k1 == (beta^5 + beta^4 + beta^3 + beta^2 + beta)*k/(beta^5 + beta^4 + beta^3 + beta^2 + beta + 1)])

Hi there. Could you provide a little more detail of what you're after? I'm not famliar with the cake eating problem, so I had to do a bit of googling to get the background needed to understand the question. As far as I can tell, you're looking at something like the example here, with A and a both set to 1 (so that the cake doesn't change size), and b set to your beta (discounted utility for eating the cake in the future):

Using the worked example in that wikipedia page, I played around with the problem. I think I have a feel for the problem, but I'm not sure quite what you're asking.

I'm running version 9.0 on Windows. The name of the installer file was SageMath-9.0-Installer-v0.6.0.exe. Below is the output I see in sage, when I check the version:

sage: version()
'SageMath version 9.0, Release Date: 2020-01-01'

I have not recompiled, and it's running on top of cygwin, so I'm not sure if the MPFR library is part of cygwin or part of the sagemath installation.

Hey, thanks for the link! I'm developing my own cython modules for SAGE, so I'll check that group out.

I can't see all the code, so I'm not sure exactly what's going on. But this particular line looks like a red flag:

 for vector in CoefficientsforSpan:

In that loop, you replaced the standard function vector() with a new variable vector. This wasn't a problem in that loop. However, the next time you tried to call the vector() function to build a new vector, it tried to use the previous vector variable instead. And that variable was an actual vector, not a function, so the error message you are seeing is just telling you that you can't call it.

Change the name of vector in that loop, and it might fix your problem. You might need to reload the notebook to fix the vector function. I can't seem to find which module it's loaded from, or I'd give you the import command to fix it. (Update: found it: from sage.modules.free_module_element import vector)

Edit: I just noticed, even further up in the code, you used vector as a variable. You'll need to use a different variable name. The code in question:

vector=NewMatrix.solve_left(Quotient[i])
CoefficientsforSpan.append(vector)

Hmm, I didn't get any hits on this. In the meantime, I think I may have answered one of my own questions. It's such a simple test that I'm kicking myself for not thinking of it sooner:

sage: a = -2.0 + 0
sage: sqrt(a)
1.41421356237310*I
sage: type(a)
<class 'sage.rings.real_mpfr.RealNumber'>
sage: type(sqrt(a))
<class 'sage.rings.complex_number.ComplexNumber'>

The + 0 part of a = -2.0 + 0 is to coerce -2.0 from RealLiteral to RealNumber. After that, it's pretty clear that ComplexNumber is the standard SAGE type for complex numbers. It automatically used that type, given a RealNumber. So I will avoid the MPComplexField class, unless I need specialized functionality from the MPC library. I can't think of what that is right now, but I guess I'm answering this for anyone else that might have the same question in the future.

If anyone else has deeper insights into the MPComplexField class, including any advantages or exclusive features of that class, I would still love to hear it.

Hmm, I checked that last one. Here's what I'm seeing:

sage: if (sin(x)>0 and cos(x)>0): print("Hello!")
sage: if (sin(x)>0 or cos(x)>0): print("Hello!")
sage: if not (sin(x)>0 and cos(x)>0): print("Hello!")
Hello!

The issue is not the RealField. The issue seems to have something to do with the precision. 28.0 is simply a RealNumber with the default precision of 53 bits. Here are my results for various precisions:

sage: erfc(RealField(53)(28))
6.56321584032878e-343
sage: erfc(RealField(64)(28))
6.56321584032878415e-343
sage: erfc(RealField(128)(28))
6.5632158403287841523809104816062747741e-343
sage: erfc(RealField(192)(28))
6.56321584032878415238091048160627477413416268994828261802e-343
sage: erfc(RealField(256)(28))
uceil_log2.c:40: MPFR assertion failed: exp < 1023
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

The real error is the "MPRF assertion failed: exp < 1023". This probably has something to do with the C implementation of mpfr_erfc, which is a third party library. I.e., it is used by SAGE, but it was not written by the SAGE team. I believe the MPFR library is still actively maintained, so maybe the SAGE team can reach out to the MPFR developers?

Edit: By the way, if you want to test with a standard double precision floating point number, put a letter 'r' after the number:

sage: isinstance(28.0, sage.rings.real_mpfr.RealNumber)
True
sage: isinstance(28.0r, float)
True
sage: erfc(28.0)
6.56321584032878e-343
sage: erfc(28.0r)
0.0

From my testing, it appears that foo is evaluating to False. Hence, in the expression "foo and bar", the foo is evaluating as False, so it skips evaluation of bar. As such, it is returning the first operand, foo, which is sin(x) > 0.

In the second expression, "foo or bar", the foo evaluates as False. With an "or" operator, the second operand must be evaluated. As such, it's returning the second operand, bar, cos(x) > 0.

You can see similar behavior of the "and" and "or" operators with the following:

sage: 0.0 and sin(x)
0.000000000000000
sage: 0.0 or sin(x)
sin(x)

Edit: Sorry, this probably didn't answer the original question. I can't tell you why foo is being evaluated as False, given the unknown value of x. However, I can reasonably assume that foo is being evaluated as False. If you plug in a value for x, like foo(2.0), then it correctly evaluates as True.

Hi everyone. I'm a long-time SAGE user, a little over a decade off and on. I have a variety of interests, but most of my coding time is spent working with matrix LU decompositions, finding Taylor series of "elementary" complex functions (logarithm or algebraic roots, e.g., log(x-c) or (x-c)^(2*pi*I/a), where c and a are complex numbers). And for years, I've been using the RealField and ComplexField classes, with their corresponding RealNumber and ComplexNumber elements, as the backbone of my code.

Just today, I discovered the MPComplexField class. I've been writing my own cython modules, borrowing code from the sage/rings/real_mpfr.pyx file. I noticed somewhere in my boilerplate code, that I was importing the MPC library. The MPC library appears to just be a C wrapper around the MPFR library, to perform complex arithmetic using pairs of MPFR numbers.

This struck me as a bit odd, because I've casually read through the source code in sage/rings/complex_number.pyx, and it looks to me like all the complex math is coded manually. E.g.,

a+b is calculated as (a.re + b.re) + I*(a.im + b.im) a*b is calculated as (a.re*b.re - a.im*b.im) + I*(a.re*b.im + a.im*b.re) sin(a) is a horrendous calculation involving sinh, square root, sine and cosine, as well as basic operations like multiplication, squaring, etc. (Yes, I paraphrased the mpfr_xxx calls to make them readable.)

In other words, the ComplexNumber class implements the complex calculations manually, whereas the MPComplexNumber class lets the library handle those calculations. Calculating sin(a) is just a call to mpc_sin().

Which leads to my question. Why the two different classes? Which one is preferred as the more SAGE-ish approach? Is there a long-term plan to switch to MPC as the default in tutorials and code examples?

I ran some simple tests, and it appears that the rounding is not the same, at least not with default settings. After a few simple arithmetic calculations, I get diverging results, which I can only assume is due to a difference in rounding, and possibly due to differing internal algorithms. I've been using the ComplexField for over a decade, so I'm hesitant to switch. But I'm wondering if the MPComplexNumber has either better performance or better rounding, at least for most common applications.

Sorry for the long post, but this MPComplexNumber class appears to have been in SAGE for quite some time (since 2008). It seems like it must be the red-headed stepchild, because I don't seem to see it get mentioned anywhere. But if the performance is better, I'd gladly make the switch in all my coding projects. Any insight or advice?

Edit: My asterisk got turned into italics, which messed up my math sections. Escaped the asterisks, hope that fixes it.