Using:

restart :
Digits := 128 :
read("D:/OneDrive/docs/Maple/observing.mpl") :

Instead of:

restart :
read("D:/OneDrive/docs/Maple/observing.mpl") :

Appears to resolve the problem.

Screen display is still rounded to 32 decimal places as set in Global Options.

Not sure why this hasn't been a problem before but I'm glad it appears to be fixable by manually setting "Digits" after each "restart".

Hmmm.  If I use:

read("D:/OneDrive/docs/Maple/observing.mpl") :

J_Luna ;

restart :

read("D:/OneDrive/docs/Maple/observing.mpl") :

J_Luna ;

Using "read" without "restart" first produces the correct assignment for "J_Luna".

But using "restart : read" produces the truncated assignment for "J_Luna".

For some reason the assignments are always truncated if "read" happens after "restart".  The correct values are only assigned if "read" is done without a "restart" first.

Is there a way to fix this?  I don't remember having this problem before so maybe it was a setting that was changed.

observing.txt

I just restarted Maple again and it is back to the way it was.  Any help here is appreciated why assignments are saving as truncated values sometimes.  I suppose I can try reinstalling Maple 2023 as a next step.

I have attached the MPL file but it has to be resaved as "observing.mpl" to read in Maple.

read("D:/OneDrive/docs/Maple/observing.mpl") :

J_Luna;

A_Luna*L_Sol/S_sphere(a_Terra);

I just restarted Maple 2023 a second time, and everything appears to be back to normal again.

This is a very concerning bug or glitch though.  Has anyone else experienced this problem in Maple 2023?  The first time I restarted Maple though it did not change anything but the second time I restarted Maple it went back to normal.  I've been using Maple 2023 for about a year now and haven't seen this happen before.

I just noticed that if you use File --> Export As --> MPL, then the Unicode exported from Maple 2023 will display properly on Notepad Plus Plus for Microsoft Windows 11.

So it looks the problem is just a display bug on Maple 2023 and also on Maple 2024.  The Unicode expressions do save correctly and can be exported to MPL, but the characters will not display in the Maple worksheet.  Hopefully this is something that might be easy to patch with an update, especially since there are now many Unicode fonts available, including the free open-source Google Noto ("no tofu") fonts.  For whatever reason, Maple 2023 and Maple 2024 are not able to utilize the Unicode fonts to properly display Unicode characters.

It looks like the other alternative would be to use unit contexts: "arcsec[angle]", "sec[angle]" (default), or "as[angle]" but that gets more verbose than using "asec" instead of "sec" or 'arcsec".

This seems to be working for now:

AddUnit(second, context = angle, spelling = arcsecond, plural = arcseconds, symbol = asec, prefix = SI_negative) ;

@acer, it's a personal preference.  I am still more used to Maxima than Maple syntax so that Maxima uses "asec" whereas Maple uses "arcsec".  So I have always written out arseconds as "arcsec" and arcsecants as "asec".

The Maple default of "sec" is still a better alternative than "arcsecond" especially for prefixed and solid-angle units such as square milliarcseconds (marcsec^2 = msec^2).  However, "sec" is still going to have the same conflicts with the secant function.  It can be defined as a unit symbol but it can't be properly used in calculations.  "asec" seems to be the best alternative to "sec" or "arcsec" for the arcsecond, e.g. masec^2 for a square milliarcsecond.  "as" is a commonly used symbol for arcseconds but it conflicts with attoseconds so should be avoided.

It would be nice if the "alias" command could deactivate the original spelling of the item so that it can be reused elsewhere.

@dharr, that is good to know.  I am curious though why you still use 2022 and 2015 if you have 2023?  Were there other features available in 2015 and 2022 that were dropped from the 2023 version?

@dharr, yes the "Remember Me" box is checked but it doesn't remember me.

If I click "Save to Cloud" it just goes back to the login page every time.  It is very annoying especially with a long complex password to type.

I am using Bitdefender Total Security for Microsoft Windows 11 Pro.

I tried disabling the firewall and antiransomware protection but no change.

@mmcdara, I just installed the 15-day trial for Maple 2024.  It looks like Maple 2024 still has the same problems with displaying Unicode characters as Maple 2023 does.

FYI, the default font for cuneiform Unicode characters on Microsoft Windows 10 and up is now "Segoe UI Historic".  If you are using Windows 10/11, you can set the Maple 2024 font to Segoe UI Historic using "Format" --> "Character" --> "Attributes" but unfortunately Maple 2024 still does not recognize the Unicode characters, even with a supported Unicode font.

It looks like Maple 2024 does recognize the characters and uses them correctly though: it just can't display the characters as anything other than tofu squares.  So it seems to be only a visual display issue, not a computational issue, which might be easy to fix in an update for Maple 2024.

I just installed the 15-day trial for the new Maple 2024 and this bug is still not fixed unfortunately, requiring a workaround instead.

@dharr, not sure if you're using the same eccentricity.  The eccentricity I got doesn't work:

AddConstant(Varda_diameter, symbol = d[Varda], value = 740., uncertainty = 14., units = km) :

AddConstant(Varda_radius, symbol = r[Varda], derive = d[Varda]/2) :

# f[Varda] := Quantity(0.080, 0.049) :
AddConstant(Varda_flattening, symbol = f[Varda], value = 0.080, uncertainty = 0.049, units = 1) :

AddConstant(Varda_eccentricity, symbol = e[Varda], derive = sqrt(2*f[Varda] - f[Varda]^2)) :

AddConstant(Varda_equatorial_radius, symbol = r[e,Varda], derive = 3*r[Varda]*sqrt(1 - e[Varda]^2)) :
AddConstant(Varda_polar_radius, symbol = r[p,Varda], derive = 3*r[Varda]*sqrt(1 - e[Varda]^2)/(2 + sqrt(1 - e[Varda]^2))) :

# AddConstant(Varda_equatorial_radius, symbol = r[e,Varda], derive = -3*r[Varda]/(f[Varda] - 3)) :
# AddConstant(Varda_polar_radius, symbol = r[p,Varda], derive = 3*(f[Varda] - 1)*r[Varda]/(f[Varda] - 3)) :

Using this has the advantage though that both the equatorial and polar radii are now dimensionless instead of only the polar radius being dimensionless.  This gives a dimensionless quantity for both area and volume, but density is in kilograms instead of kilograms per cubic meter.

Unfortunately this still creates serious problems.  For example, you can't define a derivative constant with an average density if one of the densities is in kilograms instead of kilograms per cubic meter.  Will just have to not use the ScientificConstants package until this can get fixed.

I also noticed that "with(Statistics) : Mean(%)" doesn't seem to work with Units either.

d[Varda] := Quantity(740., 14.)*Unit(km) :
f[Varda] := Quantity(0.080, 0.049) :
m[Varda] := Quantity(2.45E20, 0.06E20)*Unit(kg) :

r[Varda] := d[Varda]/2 :

r[e,Varda] := -3*r[Varda]/(f[Varda] - 3) :
r[p,Varda] := 3*(f[Varda] - 1)*r[Varda]/(f[Varda] - 3) :

V[Varda] := V_spheroid(r[e,Varda], r[p,Varda]) :

rho[Varda] := m[Varda]/V[Varda] :

rho[cubewano] := (rho[Varda] + Constant(rho[Varuna], units))/2 :

# AddConstant(cubewano_density, symbol = rho[cubewano], derive = (rho[Varda] + rho[Varuna])/2) :

A better example of how serious this bug is:

# f[Varda] := Quantity(0.080, 0.049) :
AddConstant(Varda_flattening, symbol = f[Varda], value = 0.080, uncertainty = 0.049) :

AddConstant(Varda_diameter, symbol = d[Varda], value = 740., uncertainty = 14., units = km) :

AddConstant(Varda_radius, symbol = r[Varda], derive = d[Varda]/2) :

AddConstant(Varda_equatorial_radius, symbol = r[e,Varda], derive = -3*r[Varda]/(f[Varda] - 3)) :
AddConstant(Varda_polar_radius, symbol = r[p,Varda], derive = 3*(f[Varda] - 1)*r[Varda]/(f[Varda] - 3)) :

"AddConstant" will not accept "Quantity" for "derive".  So there is no way to calculate the area or volume of this spheroid with error and units unless not using the "ScientificConstants" package, not using units, or using the eccentricity workaround.

What is most strange is that the polar radius is dimensionless but the equatorial radius has the correct units (meters).  Unfortunately this means that the volume is in square meters instead of cubic meters when multiplying the dimensioned length by the dimensionless length.

Unfortunately that doesn't seem to work either.  I opened a new thread for this new issue with integrating on Maple:

https://www.mapleprimes.com/questions/237724-Ellipsoids-With-Units-And-Error?sq=237724

A similar problem with non-cancelable units appears to occur when using the "ellipsoid" function (which uses elliptic integrals) together with Units and ScientificErrorAnalysis.

alias(asin = arcsin) :
alias(pi = Pi) :
alias(S_ellipsoid = ellipsoid) :
E := (n) -> 10^n :
with(ScientificErrorAnalysis) :
with(Units) :

_km := Unit(km) :
_lm := Unit(lm) :
_lx := Unit(lx) :
_m := Unit(m) :
_m2 := Unit(m^2) :
_rad := Unit(rad) :
_sr := Unit(sr) :
AddUnit(nit, symbol = nt, prefix = SI) :
f_Terra := 1/Quantity(298.257222101, 0.000000001) :
R_Io := Quantity(0.63, 0.02) :
R_Terra := Quantity(0.306, 0.001) :
S_ellipse := (r_e, r_p) -> pi*r_e*r_p :
S_spheroid := (r_e, r_p) -> S_ellipsoid(r_e, r_e, r_p) :

_nt := Unit(nt) :
a_Terra := Quantity(149598023., 1.)*_km :
alpha_Jupiter := Quantity(816.363, 0.001)*E(6)*_km :
A_Terra := 1 - R_Terra :
d_e_Io := Quantity(3660.0, 0.1)*_km :
d_m_Io := Quantity(3637.4, 0.1)*_km :
pi_Jupiter := Quantity(740.595, 0.001)*E(6)*_km :
Phi_Sol := Quantity(3.75, 0.01)*E(28)*_lm :
r_e_Terra := Quantity(6378.1370, 0.0001)*_km :
r_mu_Io := Quantity(1821.6, 0.5)*_km :
S_sphere := (r) -> S_spheroid(r, r) :

a_Jupiter := (alpha_Jupiter + pi_Jupiter)/2 :
r_e_Io := d_e_Io/2 :
r_m_Io := d_m_Io/2 :
r_p_Terra := -(f_Terra - 1)*r_e_Terra :

E_Sol_Io := Phi_Sol/S_sphere(a_Jupiter) :
r_e_mu_Io := (r_e_Io + r_m_Io)/2 :
r_mu_Terra := (2*r_e_Terra + r_p_Terra)/3 :
r_p_Io := 3*r_mu_Io - r_e_Io - r_m_Io :

Delta_Terra := r_mu_Terra :
M_Io := R_Io*E_Sol_Io :
S_Io := S_ellipsoid(r_e_Io, r_m_Io, r_p_Io) :

Delta_Jupiter := sqrt(a_Jupiter^2 + a_Terra^2) - Delta_Terra :
Phi_Io := M_Io*S_Io/2 :

Delta_Io := Delta_Jupiter :

E_Io := A_Terra*Phi_Io/S_sphere(Delta_Io) :
rho_e_mu_Io := asin(r_e_mu_Io/Delta_Io)*_rad :
rho_p_Io := asin(r_p_Io/Delta_Io)*_rad :

Omega_Io := S_ellipse(rho_e_mu_Io, rho_p_Io) :

L_Io := E_Io/Omega_Io : # Ionian luminance in nits (candelas per square meter)

combine(combine(L_Io, units), errors);