Enhancement: plan for calc v3

[lcn2]

This is a placeholder for TODO items needed to have the release calc version 3 (after calc 2.15.1.x is released and stable). Think of this TOOD list as a planned set of changes that will come with calc v3

Things TODO when starting work on calc v3

• [ ] create calcv2 branch on GitHub See How to Create a New Branch in GitHub - What's a Branch, Anyway? See Creating and deleting branches within your repository

• [ ] on master branch change calc version to 3.0.0

• [ ] check in to ==>> master <<== branch the calc version to 3.0.0 change as a unstable release

• [ ] use calloc(3) instead of malloc(3) were reasonable

• [ ] assume C has const use const instead of CONST eliminate use of have_const.h

• [ ] assume C has extern use extern instead of E_FUNC and EXTERN NOTE: address the DLL need for Cygwin compilers, so perhaps use external DLL instead? clean up decl.h

• [ ] assume C has static use static instead of STATIC clean up decl.h

• [ ] require <inttypes.h> eliminate use of have_inttypes.h

• [ ] require <limits.h> eliminate use of have_limits.h

• [ ] assume use of memmove() eliminate use of have_memmv.h

• [ ] assume use of memcpy() and memset()

• [ ] do not assume getprid() eliminate use of have_getprid.h eliminate code that depends on HAVE_GETPRID

• [ ] require <stdbool.h> eliminate use of have_stdbool.h eliminate use of bool.h

• [ ] require <stdint.h> eliminate use of have_stdint.h

• [ ] require <stdlib.h> eliminate use of have_stdlib.h

• [ ] require <strdup.h> eliminate use of have_strdup.h

• [ ] require <string.h> eliminate use of have_string.h

• [ ] require <unistd.h> eliminate use of have_unistd.h

• [ ] require use of <stdarg.h> eliminate use of have_stdvs.c eliminate use of have_varvs.c remove code that depends on VARARGS being defined

• [ ] assume use of vsnprintf() and vsnprintf()

• [ ] require use of c17 or later C compiler update banned.h to ban gmtime() update banned.h to ban localtime() update banned.h to ban ctime() update banned.h to ban ctime_r() update banned.h to ban asctime() update banned.h to ban asctime_r() change chk_c.c to test for c17 or later.

• [ ] eliminate BASEB == 16 option

• [ ] remove any #include of calc *.h files that are not needed

• [ ] make v_type and v_subtype an int32_t in value.h This will allow for number larger than 4GB in size

• [ ] reformat C code using Xformat The format is TBD (perhaps discussed in a comment below)

• [ ] test for support of 128-bit and also for 256-bit data types This would allow for a BASEB of 64 and 128 See issue #48

• [ ] Remove calc -O and the old classic defaults

• [ ] Change the calc default as of the following had been set: config("tilde_space",1),; config("fraction_space",1),; config("complex_space",1),;

• [ ] Support hex float constants A "hex float' matches the following regex: [+-]?0x[0-9a-f]+([.][0-9a-f]+)?(p[+-]?[0-9]+)? See issue #14 for more details.

• [ ] Document or flag as syntax error when the numerator is assumed When calc is given just /2 (no numerator), calc assumes a numerator of 1. This /x becomes equivalent of 1/x. If this a bug, then flag as a syntax error, otherwise if this a a feature then document under help/unexpected. See issue #49 for more details.

• [ ] Change #define CONFIG_SOMETHING in config.h into an enum

• [ ] Move to a 3-level version system Update README.RELEASE to use a 3 level version system. See issue #113

• [ ] Improve how someone can control where calc installs things Improve the documentation on how and where calc installs things. See issue #108

• [ ] Improve use of readline and the programmable completion feature Look into completing the names of functions, variables, and providing lists of available help files or functions See issue #115.

• [ ] Add pre-defined constants to calc See comment 1749699647 below. See also comment 1751269852, comment 1751309220, and comment 1751332488

• [ ] Release calc also as a macOS DMG for universal binary NOTE: A single DMG for x86_64 and Apple Silicon

• [ ] Release calc also as a s390x RPM NOTE: See Support self-hosted runner on linux-s390x platform NOTE: See also Run-On-Arch GitHub Action

• [ ] Release calc as a Debian ".deb" binary package NOTE: See Debian packaging

• [ ] Split help/command into separate help files Have help/read just report on the read command, for example. The help/command should be a concatenation of these separate help files. The help/command at the top should suggest help usage and help man.

• [ ] Improve help help The current help/help file need to be improved, both in the order of items presented as well as to provide topics of better interest. Consider how man perl breaks up and names sections. This might be a useful model.

• [x] Add help man to print the formatted calc man page. Replace help usage with help man and print the formatted man page. Alias help calc.1 to help man.

• [ ] Move help/functlist* outside of the help dir Put only help files and help/Makefile under the help/ directory.

• [ ] Change help/Makefile to print a special help file about calc Makefiles. Alias help makefile to help Makefile.

• [ ] Change help/usage and change calc -h to print information about the calc command line This print a short message about using the help command, and then print a typical command line usage summary.

• [ ] Add help faq to print a calc frequently asked questions file Look over open and closed discussions and old Email for various FAQ ideas.

• [ ] Explore the possibility of being able to save and restore calc history in machine ("native") form See comment 1754161473

• [ ] Integrate calc with gnuplot(1) Come up with a good way for calc to drive gnuplot. See issue #126.

• [ ] Rewrite the Blum-Blum-Shub pseudo-random number generator seed code in zrandom.c Rewrite the seed code to be a straightforward generator seeding, while maintaining backward compatibility. That is, no difference from a user's perspective. Fix the one known and minor calc memory leak as well.

• [ ] Add a pipe object

Give calc the ability to perform I/O with programs it launches: I.e., core concepts relating to "pipes, forks, and I/O with other processes, etc."

See also pull request #153 that was created by @vike2000 for additional ideas.

MORE TODOs to be added over time.

[lcn2]

Thank you for your suggestions

We wish to thank @ilyakurdyukov for issue #48 that is now part of this issue.

We wish to thank @ghost for issue #14 that is now part of this issue.

We wish to thank @Gusted for issue #49 that is now part of this issue.

We with to thank @pmetzger for issue #113, #115 and #116.

[lcn2]

Calc version 2.15.0.0 has been released. This is the last major update to calc v2 planned before we start work in calc version 3.

As we work on our initial plan for calc version 3 and update the calc v3 TODO list, we will monitor use of calc v2.15.0. Any issues reported in the short term will be addressed on the master branch and a calc version 2.15.0.x will be released.

Once all seems quiet, and our initial planning for calc version 3 is firm, we will form the calcv2 branch and begin work on the calc v3 TODO list. Should there be a need for a calc v2 bug fix release after that, we will apply such changes to the calcv2 branch.

[lcn2]

In comment 1929072414, @pmetzger suggests:

It would be nice if there were a library of predefined constants just as there's a library of predefined functions. Yes, for some things one can just do e=exp(1) or pi=pi() and so forth at the start of one's session (and I have those in particular in my calc rc file), but it's a bit annoying for beginners. Perhaps a library of common mathematical constants might be made available?

Calc could start off with certain constants as predefine variables, subject to the epsilon() precision. But what if people need a different epsilon?

Perhaps what might be needed is some "rebuild the constants to this epsilon" such as:

constants([eps])

The constants builtin would rebuild the internal constants to a specified epsilon level.

By default (unless calc was given such flag such as calc -L), calc would start out with the constants pre-set to the default epsilon value.

OK: we are talking about the constants that are not rational values. The internal constants for things like 1, 2, -1, and 10 don't count. Well they are part of counting, but you know what we mean. :-)

We also prefer to constants that are reasonably sized. We are not going to load Skewes's number for example. :-) :-) :-) We also need to restrict to constants that are easy to compute, so we are not going to compute Ackermann function related constants either :-) :-) :-). Only simple easy to compute constants. And not too many constants: we don't want to delay calc startup time too much.

If so, what constants should calc pre-define? What are their names?

• c
• pi
• e
• G

Please add your suggestions, in the form of Wikipedia links to the constants you wish calc to pre-compute and pre-define.

[pmetzger]

My own list in my .calcrc looks like this; almost all of these were added at some point because of an immediate need and then left forever. I think most of these aren't a good idea unless some sort of namespacing is provided. (Also, for constants with dimensions, it's hard to know which version of the constant one should use.)

(Adding dimensions to Calc would be interesting of course. But a lot of work! Still, it also would sometimes lead to errors being found which is quite useful.)

Anyway, I'd say "e" and "pi" are of course pretty obvious. If one adds physical constants that aren't dimensionless, they probably should be in MKS (SI) units. If one has namespaces (i.e. if one can say math.pi or phys.G or import things or what have you) then one can add an endless number of these without worrying about them interfering or polluting the namespace.

## Euler's Constant
e = exp(1)
## Pi
pi = pi()

## The Ideal Gas Constant, assuming you're working in Joules or L*kPa
Rj=8.314472
## The Ideal Gas Constant, assuming you're working in KJoules
RkJ=(8.314472/1000.0)
## Avogadro's Number
Na=6.0221415e23
## speed of light in meters per second (EXACTLY)
c_m=299792458.0
## kilometers per second
c_km=c_m/1000.0
## 1 atomsphere, in kPa
StdP=101.325
## hbar
hbar=1.05457E-34
## boltzmann's constant
kb=1.38065E-23

[ilyakurdyukov]

we don't want to delay calc startup time too much

You can perform calculations the first time the constant is used. This way you don't have to calculate all the constants at startup.

[pmetzger]

@ilyakurdyukov So lazy computation? Though I suspect that if it's just a few things (like pi and e) the time spent will be ignorable.

[lcn2]

We like the idea of pre-defining constants.

The effect of this calc v3 idea is that one would be able to do:

$ calc
C-style arbitrary precision calculator (version 3.x.y)
Calc is open software. For license details type:  help copyright
[Type "exit" to exit, or "help" for help.]

; sin(pi/3)
	0.86602540378443864676
;

and it would just work.

In many cases the constants could be compiled in so that no startup time would be required. Given the default epsilon, the const.c would be modified to include these pre-compiled values.

Internally calc as a number of constants. If you look at the start of qmath.c and commath.c you will see a few. However this internal values are for the convenience of builtin functions so that values such as 1 and 2 do not have to be allocated and used over and over again. However ... such internal constants are NOT visible in the variable name space. Moreover, we are NOT considering add variables such as one to contain 1. Because one already has a constant symbol: 1 :-)

To state the obvious, calc is in wide use in area of the world where English is not the native language: so English names are NOT good choices for constants. Thankfully in physics, math, engineering, the sorts of constants are mostly in language independent form.

However in cases where the constant symbol is, say, a Greek letter, we need to use an ASCII equivalent set of letters, so we would use "pi".

We would add a new builtin function, such as:

constants([eps])

that would re-compute the internal constants using the epsilon or precision supplied value. So if someone wanted to work with constants to only 10 decimal places:

constants(1e-10)

The existing show command would be expanded to show the pre-defined constants:

show constants

We would probably print the pre-defined constants ahead of the internal constants table. Or we would add a different show command such as:

show predefined

And of course there would be a help file:

help constants

that would explain the new constants([eps] built-in function, and something like (we are just guessing at names for now) would be one of the pre-built help files that showed the result of show constants.

help predefined

Someone is free to reassign the value of a constant. Say, for example, that i is a constant pre-defined to the square root if -1, and some did:

for (i=0; i < 10; ++i) { print i; }

Well just any variable they just changed a calc variable and that is fine.

Nevertheless doing:

for (i=0; i < 10; ++i) { constants(10 ^ -i); }

would NOT work as expected if i were such a constant. Calling the constants() builtin would be like doing:

read myconstants.cal

UPDATE 0a

As stated above, there would be a command line option to NOT pre-define constants. Again we are guessing at the option name here, nevertheless doing something like (the letters c, C, and p already are in use,. so P for no-predefined?):

calc -P

Such a command line flag would keep the constant variables out of the name space.

We would also rename the current file help/const.cal to something else.

UPDATE 1

We are thinking that the list of constants would not be too long. The output of:

show predefined
help predefined

would NOT print pages and pages of constants. It would just a reasonable list.

[lcn2]

Some care would need to be used in determining which constants were pre-defined and what values they would have.

Consider these lists of constants:

• Wikipedia Mathematical constants and Wikipedia List of mathematical constants
• MathWorld Constants
• Finch's Mathematical Constants
• Wikipedia Physical Constants and Wikipedia List of physical constants
• Gold Book Physical Constants
• The Engineering ToolBox Physical Constants
• NIST Meet the Constants
• Engineering.com Constants

There are far too many to include them all, and there are far too many constants that have a very narrow use case.

Worse still, there are conflicting content names. For example:

• e in Mathematics
• e in particle physics

In the above conflict, the mathematical version would be used.

Then there is the question of units. Consider the Gas constant R:

• Gas Constant

We would probably go with the SI constant value instead of trying to include variations such as for "L⋅bar⋅K−1⋅mol−1", or "erg⋅K−1⋅mol−1", or "m3⋅atm⋅K−1⋅mol−1", etc.

UPDATE 0a

During this calc v3 planing phase, we would in this issue #103, come up with a proposed table of pre-defined constants that would specify:

• constant variable name
• constant numerical value (subject to the default rounding mode and default epsilon value: 1e-20)
• string that describes the constant
• URL reference for the constant

We would then invite people to comment, suggest and correct such a table before implementing.

[pmetzger]

Yes, the SI (i.e. MKS) units are probably the best.

I still suspect some sort of namespacing might be best for most things other than e or pi; that way you can request the physics version of alpha or the math version or what have you.

[lcn2]

Yes, the SI (i.e. MKS) units are probably the best.

I still suspect some sort of namespacing might be best for most things other than e or pi; that way you can request the physics version of alpha or the math version or what have you.

Interesting idea. While the pre-compiled table could have a default, one could switch via:

config("constant", "physics");
config("constant", "math");
config("constant", "default");
config("constant", "none");

and use a calc command line option such as:

calc -P physics
calc -P math
calc -P default
calc -P none

In the above cases, the "none" option would disable all constants. The "default" would be the default set. :-)

So if "pi" were defined:

$ calc
C-style arbitrary precision calculator (version 3.x.y)
Calc is open software. For license details type:  help copyright
[Type "exit" to exit, or "help" for help.]

; ln(pi)
	1.14472988584940017414

and then you did:

; config("constant", "none");
        "default"

then this would happen:

; pi^2
"pi" is undefined

The effect of switching to a constant table would be to assign null() to those constants in the old space that were NOT in the new space.

[pmetzger]

I was thinking more of something like math.phi (for the golden ratio) and physics.G (for the gravitational constant) myself. Maybe pi and e are too common for that, but many of the others aren't. One could also use phi=math.phi to "import" a single identifier or have a thing likeimport("math") for those that don't want to deal with qualified identifiers at all.

[lcn2]

I was thinking more of something like math.phi (for the golden ratio) and physics.G (for the gravitational constant) myself. Maybe pi and e are too common for that, but many of the others aren't. One could also use phi=math.phi to "import" a single identifier or have a thing likeimport("math") for those that don't want to deal with qualified identifiers at all.

Calc does have objects. Perhaps that might be useful. On the other hand that might be an unnecessary complication given that people would want "pi=math.pi" anyway.

We suggested in comment 1751332488, calc would have a different constant sets with the "default" set being the default :-). Even though calc might start out with a "math", "physics", "default" constant set combo, more sets could be easily added such as "astronomy" or "statistics" or "number_theory" if it turned out that the "math" or "physics" constant set was too limited or that the constant variable names in those sets needed to change.

The next thing to do is to propose what the initial constants sets contain. I.e., we need to determine:

• constant set name
• string that describes the constant set

And then for each constant set, we need a list of:

• constant variable name
• constant numerical value (subject to the default rounding mode and default epsilon value: 1e-20)
• string that describes the constant
• URL reference for the constant

Again, these constant sets would be compiled into calc. The calc -P setname and config("constant", "setname") would allow for someone to easily specify a set. And the set name of "none" would have no constants.

[kcrossen]

Presumably, when the constants are assigned to variables, they will "will" no properties for their assignees to "inherit".

Ken

On Sat, Oct 7, 2023, 4:15 PM Landon Curt Noll @.***> wrote:

I was thinking more of something like math.phi (for the golden ratio) and physics.G (for the gravitational constant) myself. Maybe pi and e are too common for that, but many of the others aren't. One could also use phi=math.phi to "import" a single identifier or have a thing like import("math") for those that don't want to deal with qualified identifiers at all.

Calc does have objects. Perhaps that might be useful. On the other hand that might be an unnecessary complication given that people would want "pi=math.pi" anyway.

We suggested in comment 1751332488 https://github.com/lcn2/calc/issues/103#issuecomment-1751332488, calc would have a different constant sets with the "default" set being the default :-). Even though calc might start out with a "math", "physics", "default" constant set combo, more sets could be easily added such as "astronomy" or "statistics" or "number_theory" if it turned out that the "math" or "physics" constant set was too limited or that the constant variable names in those sets needed to change.

The next thing to do is to propose what the initial constants sets contain. I.e., we need to determine:

• constant set name
• string that describes the constant set

And then for each constant set, we need a list of:

• constant variable name
• constant numerical value (subject to the default rounding mode and default epsilon value: 1e-20)
• string that describes the constant
• URL reference for the constant

Again, these constant sets would be compiled into calc. The calc -P setname and config("constant", "setname") would allow for someone to easily specify a set. And the set name of "none" would have no constants.

— Reply to this email directly, view it on GitHub https://github.com/lcn2/calc/issues/103#issuecomment-1751809174, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO4OEATMBAR2CJOTTYEWBTX6GZ6PAVCNFSM6AAAAAA5R3V5KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJRHAYDSMJXGQ . You are receiving this because you were mentioned.Message ID: @.***>

[lcn2]

Presumably, when the constants are assigned to variables, they will "will" no properties for their assignees to "inherit".

Correct. The variables will have numerical values (rational (NUMBER) or complex rational (COMPLEX)) to the precision of the epsilon value. No special properties. Easy to change or remove. And if the "none" constant set is used (by invoking calc -P none or calling config("constant", "none") they go away.

[kcrossen]

Alternate (and elegant) solution to my initial "inheritance" issue. Control of "inheritance" still a good feature.

My test project was arbitrary precision calculator for which typical constants (pi, e, etc.) are minimum viable. Large step forward.

My #1 requirement to package calc as a Qt/C++ object is to sandbox calc. No system i/o, no possible/potential modification of environment. This is Qt's foundational security posture, any operation outside sandbox guaranteed to be explicit. My solution was to no op all i/o, file system, etc. and create a function layer that executes arbitrary calc programs and returns the results. This layer also manages memory alloc/release to guarantee no leakage.

Ken

On Sat, Oct 7, 2023, 8:54 PM Landon Curt Noll @.***> wrote:

Presumably, when the constants are assigned to variables, they will "will" no properties for their assignees to "inherit".

Correct. The variables will have numerical values (rational (NUMBER) or complex rational (COMPLEX)) to the precision of the epsilon value. No special properties. Easy to change or remove. And if the "none" constant set is used (by invoking calc -P none or calling config("constant", "none") they go away.

— Reply to this email directly, view it on GitHub https://github.com/lcn2/calc/issues/103#issuecomment-1751879774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO4OEDDBGI4PAFQIAFMEZLX6H2VJAVCNFSM6AAAAAA5R3V5KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJRHA3TSNZXGQ . You are receiving this because you were mentioned.Message ID: @.***>

[pmetzger]

e and pi are clearly too common to want to have qualified, but G or k_b (Boltzmann's constant) might not be common enough to want in the main namespace by default.

[lcn2]

My # 1

as in main or primary, not issue #1 that was resolve in 2018. 😁

requirement to package calc as a Qt/C++ object is to sandbox calc. No system i/o, no possible/potential modification of environment. This is Qt's foundational security posture, any operation outside sandbox guaranteed to be explicit. My solution was to no op all i/o, file system, etc. and create a function layer that executes arbitrary calc programs and returns the results. This layer also manages memory alloc/release to guarantee no leakage.

Your idea, @kcrossen, of separation is a very interesting one. We would like to explore it some more:

QUESTIONS ABOUT SEPARATION

We need to better understand that qualifies as "separate".

Question 1:

We need to ask about printing error messages.

Does the printing of an error message to stderr violate the "separation" concept?

Question 2:

We need to ask about the conditional printing of error messages.

Assume there was a disable_calc_error_msg flag that, when != 0, prevented functions from printing debug messages. Assume that disable_calc_error_msg was initialized by default to 0.

Assume your application could set disable_calc_error_msg to a non-zero value such as 1, before calling any calc related functions.

Would functions that used that mechanism to allow or disable debug messages, quality as "separate" under "separation" concept?

Question 3:

We need to ask about the possibly of printing a debug messages.

Assume there was a disable_calc_debug_msg flag that, when != 0, prevented functions from printing debug messages. Assume that disable_calc_debug_msg was initialized by default to 0.

Assume your application could set disable_calc_debug_msg to a non-zero value such as 1, before calling any calc related functions.

Would functions that used that mechanism to allow or disable debug messages, quality as "separate" under "separation" concept?

Question 4:

We need to ask about a function calling math_error() in regards to separation.

In math_error(), a long jump to calc_matherr_jmpbuf is ONLY done when calc_use_matherr_jmpbuf is != 0. The calc_use_matherr_jmpbuf variable is initialized to 0.

Assume your application could set calc_use_matherr_jmpbuf to a non-zero value such as 1, before calling any calc related functions.

Would function that call math_error() quality as "separate" under "separation" concept?

UPDATE 0

There are very good reasons for asking what seems like 4 similar questions. If you could answer each question separately, @kcrossen, that would be appreciated.

[lcn2]

e and pi are clearly too common to want to have qualified, but G or k_b (Boltzmann's constant) might not be common enough to want in the main namespace by default.

It seems, @pmetzger, reasonable that e and pi would be in the "default", "math" and "physics" constant sets (however constant sets are implemented).

Question for all

Consider the case of Boltzmann constant. It would be very reasonable to include that in the "physics" constant set.

What should the name of that constant be in calc? Which name do you prefer?

0. Kb
1. K_b
2. kb
3. k_b

[lcn2]

Alternate (and elegant) solution to my initial "inheritance" issue. Control of "inheritance" still a good feature.

Interesting point, @kcrossen. Calc does have the concept of scope. Consider a valuable that is declared local:

local curds = 5;

Local variables are visible only within a single function or command sequence. When the function or command sequence returns, the local variables are deleted.

So if we have an import(constant_set) function, that could have the effect of declaring the constants as local.

For example:

import("math_constant");        /* assume this means import the math constant set */

or

import("math.constant");        /* assume this means import the math constant set */

That would have the effect of:

local pi = ...;
local e = ...;
local gamma = ....;
etc.

[kcrossen]

Not claiming this to be optimal: Calc, in my model, is a pure interpret/compute/"side-effects" storage engine. It is wrapped in a "thunk" that handles memory management, receives executable text and returns text results while presenting itself as a Qt/C++ object. Garden variety Qt (GUI in my case) wraps this wrapper with a UI having minimal/controlled access to the opsys.

APCalc uses Calc to generate/manipulate/store the array that represents a calculator stack, dictionaries of (user, built-in) variables and functions, plus built-ins such as a generalized Newton's method engine that can solve arbitrary (well behaving) financial & scientific equations. In general, Calc returns either a single value or the entire (RPN) stack expressed as displayable text. All of this is absurdly fast w/ 100 digit precision. Maybe not as fast as FPU, but fast enough not to be perceptibly slower.

There is also a project to benchmark this code on different Opsys/CPUs. For example, computing 1M different sin/cos on ARM is about 3X faster than on Intel at similar clock speed. Compiler choice and opsys essentially irrelevant.

Ken

On Mon, Oct 9, 2023, 3:53 PM Landon Curt Noll @.***> wrote:

My # 1

as in main or primary, not issue #1 https://github.com/lcn2/calc/issues/1 that was resolve in 2018. :-)

requirement to package calc as a Qt/C++ object is to sandbox calc. No system i/o, no possible/potential modification of environment. This is Qt's foundational security posture, any operation outside sandbox guaranteed to be explicit. My solution was to no op all i/o, file system, etc. and create a function layer that executes arbitrary calc programs and returns the results. This layer also manages memory alloc/release to guarantee no leakage.

Your idea, @kcrossen https://github.com/kcrossen, of separation is a very good one. We would like to explore it some more: Questions about separation

What qualifies is separate? Would there need to be two libraries: libcaicio and a libcalc such that if one linked to libcalc only, no calc I/O would be involved?

Does the printing of an error message to stderr qualify is I/O, and thus would that action need to be "separated"?

Does the possibly of printing a debug message, quality has "separation violation"? Assume that the debug message was only enabled if a given flag was non-zero. What if there was a no_calc_IO flag that, when zero, prevented functions from printing error and debug messages. Assume that no_calc_IO was initialized to 0 and the application never set it to non-zero. Would that quality under the "separation" concept?

Would a function calling math_error() and potentially doing a long jump quality has "separation violation"?

Asume that taking the long jump could result in error message being issued.

FYI: In the math_error() long jump case, a long jump to calc_matherr_jmpbuf is ONLY done when calc_use_matherr_jmpbuf is != 0. In the same math_error() long jump case, a long jump to calc_scanerr_jmpbuf is ONLY done when calc_use_scanerr_jmpbuf is != 0. Both calc_use_matherr_jmpbuf and calc_use_scanerr_jmpbuf are initiated to 0. So if the application never sets either to non-zero. then calling math_error() results in an exit.

Would a function calling math_error() AND that does NOT change both calc_use_matherr_jmpbuf and calc_use_scanerr_jmpbuf to non-zero quality under the "separation" concept?

— Reply to this email directly, view it on GitHub https://github.com/lcn2/calc/issues/103#issuecomment-1753643535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO4OEAXO4LRSPLYNELBMC3X6RI4BAVCNFSM6AAAAAA5R3V5KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTGY2DGNJTGU . You are receiving this because you were mentioned.Message ID: @.***>

[kcrossen]

Stack values can be returned as text or in Calc-native form. So when a "history" item, even if retrieved from a stored history file, is reused, it retains its native precision. History items can be annotated.

On Mon, Oct 9, 2023, 3:53 PM Landon Curt Noll @.***> wrote:

My # 1

as in main or primary, not issue #1 https://github.com/lcn2/calc/issues/1 that was resolve in 2018. :-)

requirement to package calc as a Qt/C++ object is to sandbox calc. No system i/o, no possible/potential modification of environment. This is Qt's foundational security posture, any operation outside sandbox guaranteed to be explicit. My solution was to no op all i/o, file system, etc. and create a function layer that executes arbitrary calc programs and returns the results. This layer also manages memory alloc/release to guarantee no leakage.

Your idea, @kcrossen https://github.com/kcrossen, of separation is a very good one. We would like to explore it some more: Questions about separation

What qualifies is separate? Would there need to be two libraries: libcaicio and a libcalc such that if one linked to libcalc only, no calc I/O would be involved?

Does the printing of an error message to stderr qualify is I/O, and thus would that action need to be "separated"?

Does the possibly of printing a debug message, quality has "separation violation"? Assume that the debug message was only enabled if a given flag was non-zero. What if there was a no_calc_IO flag that, when zero, prevented functions from printing error and debug messages. Assume that no_calc_IO was initialized to 0 and the application never set it to non-zero. Would that quality under the "separation" concept?

Would a function calling math_error() and potentially doing a long jump quality has "separation violation"?

Asume that taking the long jump could result in error message being issued.

FYI: In the math_error() long jump case, a long jump to calc_matherr_jmpbuf is ONLY done when calc_use_matherr_jmpbuf is != 0. In the same math_error() long jump case, a long jump to calc_scanerr_jmpbuf is ONLY done when calc_use_scanerr_jmpbuf is != 0. Both calc_use_matherr_jmpbuf and calc_use_scanerr_jmpbuf are initiated to 0. So if the application never sets either to non-zero. then calling math_error() results in an exit.

Would a function calling math_error() AND that does NOT change both calc_use_matherr_jmpbuf and calc_use_scanerr_jmpbuf to non-zero quality under the "separation" concept?

— Reply to this email directly, view it on GitHub https://github.com/lcn2/calc/issues/103#issuecomment-1753643535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO4OEAXO4LRSPLYNELBMC3X6RI4BAVCNFSM6AAAAAA5R3V5KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTGY2DGNJTGU . You are receiving this because you were mentioned.Message ID: @.***>

[ilyakurdyukov]

https://github.com/notifications/unsubscribe-auth/<some-encoded-data>

To @kcrossen: Consider stopping answering by email without removing this link, anyone can click on it and unsubscribe you.

[ghost]

Please add JIT compiled support. Like what I said, JIT compiled is very different from compiled in the sense of language like C/C++. JIT compiled is compile the code you are executing on the fly for better performance. One example is LuaJIT.

[ghost]

Without JIT, pure interpreted code is very slow. As @pmetzger said on my thread, it's about more than 40 minutes to complete. With JIT, it only took a few minutes to complete.

[lcn2]

Without JIT, pure interpreted code is very slow. As @pmetzger said on my thread, it's about more than 40 minutes to complete. With JIT, it only took a few minutes to complete.

Well it took 165 seconds actually: he was going back of the envelope calculations assuming an execution rate that off by more than an order of magnitude. Nevertheless your point about a JIT is well taken.

UPDATE 0

I have added a TODO to explore the JIT idea. I am not sure what that would involve nor how it would be done at this point. Nevertheless the idea is an interesting one that you have raised, @3oheicrw-ver2. Thanks!

[lcn2]

https://github.com/notifications/unsubscribe-auth/<some-encoded-data>

To @kcrossen: Consider stopping answering by email without removing this link, anyone can click on it and unsubscribe you.

I agree with you, @ilyakurdyukov.

FYI: @kcrossen:

As discussion #103 is a public form for planning calc version 3.

Please consider responding to comments by making comments directly in GitHub.

UPDATE 0

Moved text to new comment due to a revision.

[pmetzger]

Building a JIT for calc would be months of work and would benefit very few people. It would also make the codebase very fragile and hard to port without specialized work on dozens of platforms.

calc is mostly a desk calculator. It's very fast for that purpose on modern hardware. It's nice that one can write calc scripts and do more sophisticated work in it, and I appreciate that facility. However, if one is trying to do something like running a large computation project that might involve hours or days of computation, it's almost certain that using a more ordinary performance-oriented compiled language will be faster and better, even given a JIT.

[pmetzger]

Consider the case of Boltzmann constant. It would be very reasonable to include that in the "physics" constant set.

What should the name of that constant be in calc? Which name do you prefer?

Kb
K_b
kb
k_b

Traditionally, it's kB or k(sub)B. Using "TeX" notation, k_B or k_b seems reasonable to me.

[lcn2]

I don't understand what you said. With JIT, everything is compiled on the fly when you executing the code. Nothing to save and restore here.

Sorry, we responded to the wrong comment. Please ignore our message. We'll delete our reply and respond to the correct message, @3oheicrw-ver2

[lcn2]

Stack values can be returned as text or in Calc-native form. So when a "history" item, even if retrieved from a stored history file, is reused, it retains its native precision. History items can be annotated.

I think this is a request, if I understand your remark to consider giving calc the ability to save and restore history on machine (what you seem to call "native") form.

We are not sure of all the implications of such a feature. Nevertheless we have added it as a TODO to consider it.