@sand15, as far as I can tell, neither the Units or ScientificConstants packages have been updated since at least 2011.  Many units and physical constants in Maple 2023 are incorrect.  This is particularly bad because the SI base units were redefined in 2019 so that quantities expressed in SI units on Maple 2023 are incorrect.  Specifically, Maple 2023 is using "ampere[2018]", "kelvin[2018]", "kilogram[2018]", and "mole[2018]" as base units.  If you go through the trouble of using "AddUnit" to redefine the SI base units with "context = 2019", then the Avogadro constant, Boltzmann constant, Planck constant, etcetera, all become exactly defined values with zero uncertainty but you have to create those as new constants as well ("new_Planck_constant" or "h[2019]") because Maple 2023 does not support "RemoveConstant" or "RemoveUnit".  I've already sent an email to Maplesoft about these major errors.

https://en.wikipedia.org/wiki/2019_redefinition_of_the_SI_base_units

@sand15, Maple 2023 is still using the old SI units and physical constants from before 2019.  The Boltzmann constant (k), Planck constant (h), Stefan-Boltzmann constant (sigma), celerity constant (c, speed of light), the IAU nominal Solar temperature (T_N_Sol), the IAU nominal Solar radius (R_N_Sol), and the IAU nominal Solar luminosity (L_N_Sol) are all exactly defined values with zero uncertainty.  For this example, the only inputted quantity with any uncertainty is the physical (non-nominal) effective temperature (T_eff).

@Carl Love, I have the global default setting for "Tools" --> "Options" --> "Precision" as "round calculation to 32 significant digits".  Setting it back to 16 significant digits removes the error.

6.2938592470335950467548474587301*10^7 - (3.1415926535897932384626433832795*10^(-45))*I

6.293859247033588*10^7

Presumably the error also does not occur on Maple for Excel because Excel automatically limits precision to 16 digits.

The imaginary part is sufficiently infinitesimal that it is easily spotted as an error so it looks like the fix for this is to evaluate using "evalf[16]" instead of "evalf".  With the relative uncertainty of the effective temperature being 10^(-4), sixteen digits of precision is likely more than sufficient here.

Using "evalf[24]" also gives a complex answer:

6.29385924703359504675483*10^7 + (3.18808822486292217839189*10^(-33))*I

@dharr, that's a nice workaround with the eccentricity; thanks.

This still seems like a bug because negative numbers as well as both positive and negative exponents (including negative irrational exponents) are all valid values for "AddConstant".  If you try to create a constant with a trigonometric or logarithmic function though it will return an error message.  This is still problematic because for example there is no way to add "Solar_area" or "Solar_luminosity" using "AddConstant" unless you approximate the Sun as a sphere instead of as an oblate spheroid (biaxial ellipsoid).  There should at least be an exception allowed for the "ellipsoid" function since this is important for areal constants in astronomy and geophysics.

The "ScientificConstants" and "Units" packages apparently haven't been updated since at least 2011 since a lot of the values for both the units and the physical constants are wrong.  Most importantly, the values of SI units and values expressed in SI units for Maple 2023 are wrong since they are using the pre-2019 unit definitions.  I already sent an email to MapleSoft about this.  Trying to manually correct all of the erroneous values built into Maple 2023 is time-consuming and problematic, especially since there is no way way to remove the symbols for units or constants.

Adding commands for "RemoveUnit" and "RemoveConstant" would allow users to make corrections more easily.

If there is only one thing I could have fixed with Maple 2023, it is to add full Unicode support.  Both Maxima (which is completely free and open-source) and Wolfram Mathematica support Unicode but this is ominously missing from Maple 2023.

Having Maple to be able to load online resources is a close second but probably an easier fix than adding Unicode support.  "Import" can only load MPL files from URLs as text strings and refuses to read as Maple input.

@dharr, I just saw that Maxima has a string trimming ("strim") command as part of its string processing ("stringproc") package that will remove string quotation marks and/or comment notation marks from inputted text.

(%i1) "/* comment */" $
(%i2) strim(" /*",%);
(%o2) comment

I can't find an equivalent for this in the Maple Help though.  This appears to be different from "parse" since all it does is trim off the starting and ending quotation marks.

@dharr, yeah I give up.  I think the problem is that both "parse" and "eval" are not evaluating the entire worksheet.  I would like to see this fixed in a Maple update though.  Seems like it should be simple enough to evaluate Maple input from a remote server since it can already read the MPL as text.  I would like to see something like this supported on Maple:

Import("https://www.nasa.gov/stars.mpl"):
Import("https://www.nasa.gov/asteroids.mpl"):
Import("https://www.nasa.gov/occultations.mpl"):

The big advantage is if using an online version, you don't have to re-download the files every time they are updated.

Is there another file format besides MPL that I can use to allow Maple to use functions, constants, and data hosted on a public server without needing to download an offline copy?  MapleCloud doesn't seem to work: it won't save my login and I can't download or upload any content.

Getting a little bit closer.  It is only partially working right now.  Not exactly sure how to set this up using "lastread" and "offset" correctly.

Not mentioned in the help documentation, but I found online: "The parse command does not evaluate the expression it returns. You must use the eval command to evaluate the expression explicitly."

eval(parse(Import("https://www.nicolesharp.net/testbox/test.mpl")));

https://eecs.umich.edu/dco/docs/maple/intropg.pdf

@dharr, it looks like the Import command adds quotation marks at the beginning and end of the MPL file so that the entire MPL file is read as a text string instead of as a list of Maple commands.  I wonder if there is a way to just remove the quotation marks from the imported text string to get it to read correctly?

According to the Help documentation: "A string containing an expression or a statement expressed in Maple syntax can be converted to an actual expression or be executed as an actual statement by using the parse function."

Unfortunately, adding "parse" doesn't seem to work either.

parse(Import("https://www.nicolesharp.net/testbox/test.mpl"));

@dharr, this isn't a good solution because it requires the user to re-download the file every time it is updated, instead of reading the file directly from the web server as it is updated in real time.  For example, I just fixed the error of "alias(pi, Pi)" which should be "alias(pi = Pi)" instead.  The newly updated file is on the server, but the end user does not know it has been updated unless they check the server directly.  Loading the MPL directly from the server ensures that the code loaded is always with the most recent version.

Obviously Maple can read the text of the MPL file so I would consider this a bug that should be fixed with the Import or Get commands to be able to use MPL files on remote servers.  Using the online version of the MPL file would be no more or less of a security risk than manually downloading the file for offline use.

The Maple 2023 Help documentation specifically states that MPL is a supported file format for the Import command so that would indicate it is a bug with the software if the MPL is not imported correctly.

@acer , both "9E9" and "9e9" produce the same result.  However, there seems to be a bug whereby when using "9E9" or "9e9" instead of "9*10^9", the displayed results are inconsistent, sometimes in the notation of ".9e8" and sometimes in the notation of "9000000000" (neither of which is standard scientific notation).  The only way to always get the same displayed results is to use "9*10^9" instead.

Specifically from my original post:

=maple("2*6371.0084E3")

=maple("2*2574.73E3")

will give results using two different notations but

=maple("2*6371.0084*10^3")

=maple("2*2574.73*10^3")

will both give results in the same notation.

This appears to be a bug since there does not seem to be any logical explanation for why the results are in two different notations when using 16+ digits of computation.

Still having a problem here. Setting Maple Excel Options Numeric Output Format Maple Precision as 32 digits of computation and Excel Format Cells as Scientific Number with 16 decimal places returns =maple("evalf(Pi)") as 3.1415926535897900E+00 and not as 3.1415926535897932E+00. Any suggestions how to fix this?

Setting Excel Format Cells as Scientific Number with 30 decimal places still only returns 3.141592653589790000000000000000E+00. Maple Options Global Precision is set to round calculations to 32 significant digits.

Never mind. Excel doesn't give error messages so you have to check directly on Maple for any syntax error messages. Stefan-Boltzman constant should be instead: evalf(2*Pi^5*(1.380649*10^(-23))^4/(15*299792458^2*(6.62607015*10^(-34))^3)). On Maxima, you are not required to add parentheses for 6.626*10^-34 but this is required on Maple: 6.626*10^(-34).

I got the numbers looking normal.  Set Maple Excel Options Numeric Output Format to Excel Format with Maple Precision of 16 digits of computation.  Then set Excel Format Cells as Scientific Number with 16 decimal places.  Finally close and restart the Excel application to see the changes.

However, the Stefan-Boltzmann constant still displays as only 0.0000000000000000E+00 even when replacing Pi with 3.1415927 and 299792458 with 299792458.0.

Maple 2023 for Microsoft Excel 365 also seems unable to display the Stefan-Boltzmann constant. =maple("evalf(2*(Pi^5)*(1.380649*(10^-23))^4/(15*(299792458^2)*(6.62607015*(10^-34))^3))") displays only as 0.