search

lcn2 / calc

C-style arbitrary precision calculator
http://www.isthe.com/chongo/tech/comp/calc/index.html
Other
359 stars 52 forks source link

Enhancement: plan for calc v3 #103

Open lcn2 opened 1 year ago

lcn2 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?

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

pmetzger commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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:

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:

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

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

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:

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

pmetzger commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?

  1. Kb
  2. K_b
  3. kb
  4. k_b
lcn2 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

kcrossen commented 1 year ago

Not a request, this history is already a consequence of my APCalc-specific wrapper. Not necessarily applicable to other users. Deeper dive, APCalc must interact w/ user which requires stack rendered in text at requested display precision. History requires both text/display precision and internal num/denom compute precision, i.e. native. The native form is required when user needs to continue calculating from a history value w/o sacrificing precision. All of this is outside my Qt/C++ object/thunk wrapper. This wrapper delivers an interpret/compile/programmable arbitrary precision compute engine that can, for example, emulate any HP calculator ever made extended to handle units by representing each SI unit category (distance, time, etc.) as a different prime number. Unit cancelation is then trivial consequence of calc internal design.

On Tue, Oct 10, 2023, 5:50 PM Landon Curt Noll @.***> wrote:

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.

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

kcrossen commented 1 year ago

More on units: Suppose 2 is time in seconds, 3 is distance in meters, 5 is mass in grams, etc. Then velocity (magnitude of) is 3/2, area is 33, acceleration is 3/(22), etc. The two components (num/denom) of the internal rational number are factored into primes to derive result units. Some operations may result in undefined units e.g. sqrt(distance).

On Tue, Oct 10, 2023, 11:02 PM Ken Crossen @.***> wrote:

Not a request, this history is already a consequence of my APCalc-specific wrapper. Not necessarily applicable to other users. Deeper dive, APCalc must interact w/ user which requires stack rendered in text at requested display precision. History requires both text/display precision and internal num/denom compute precision, i.e. native. The native form is required when user needs to continue calculating from a history value w/o sacrificing precision. All of this is outside my Qt/C++ object/thunk wrapper. This wrapper delivers an interpret/compile/programmable arbitrary precision compute engine that can, for example, emulate any HP calculator ever made extended to handle units by representing each SI unit category (distance, time, etc.) as a different prime number. Unit cancelation is then trivial consequence of calc internal design.

On Tue, Oct 10, 2023, 5:50 PM Landon Curt Noll @.***> wrote:

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.

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

lcn2 commented 1 year ago

More on units: Suppose 2 is time in seconds, 3 is distance in meters, 5 is

mass in grams, etc. Then velocity (magnitude of) is 3/2, area is 3*3,

acceleration is 3/(2*2), etc. The two components (num/denom) of the

internal rational number are factored into primes to derive result units.

Some operations may result in undefined units e.g. sqrt(distance).

sqrt(distance) is a valid unit

In physics "sqrt(distance)" is a valid unit and is not undefined!

Units with "sqrt(distance)" do show up in both physics and engineering. For example, Polarization Mode Dispersion uses units of the form of "time per sqrt(distance)".

Calc constants do not have units

Your comment does not seem relevant as the constants being planned for calc v3 are dimensionless (I.e., just numerical values).

The calc documentation will indicate the motivation for each given value, and that will include units that were used to produce the constant, an and reference (such as a URL). This will allow calc users of those constants to apply and necessary unit conversion factors.

Are comments about your app off topic?

If your above comment, @kcrossen was relevant to only your application and not to calc v3 planning, then this forum might not be the proper place to make such statements.

lcn2 commented 1 year ago

Regarding our previous remark, @kcrossen:

Meanwhile consider responding if you will, in this forum (not Email) to:

* [Questions about separation](https://github.com/lcn2/calc/issues/103#issuecomment-1753643535)
* [issuing a pull request relating to your inheritance idea](https://github.com/lcn2/calc/issues/103#issuecomment-1753700379)

On further reflection, and in regards to your idea about your inheritance:

* [issuing a pull request relating to your inheritance idea](https://github.com/lcn2/calc/issues/103#issuecomment-1753700379)

The idea changing inheritance is not within the scope of calc v3. Thus, we have removed it from the calc v3 todo list.

However: If you wish to have your idea about inheritance added to calc, then please submit a GitHub pull request within the next 2-3 weeks so that it might be added to calc v2.14.0.2.

In regards to:

* [Questions about separation](https://github.com/lcn2/calc/issues/103#issuecomment-1753643535)

If you wish to for I/O separation to be considered in calc v3, then you will need your answers to each of the questions in Questions about separation, otherwise we cannot consider such an change.

You did not seem to respond to previous requests about the above topics. Not sure why.

UPDATE 0

We will assume that a lack of a pull request in the next 2-3 weeks, or even a lack of a request for help in forming such a pull request, is due to a lack of interest on your part in an "enhanced" inheritance model for calc.

We will also assume your not answering our 4 questions about "separation" as a lack of interest on your part in such an architectural consideration for calc v3 that involves I/O separation.

UPDATE 1

Added clarification link and minor wording change to the UPDATE 0 text above.

lcn2 commented 1 year ago

Any ideas about how let calc work the gnuplot(1) / GnuPlot command would be welcome.

lcn2 commented 1 year ago

After further consideration JIT or calc is beyond the above of calc version 3 planning. As such we have marked the JIT related comments as obsolete and removed the reference to JIT from the TODO list.

lcn2 commented 1 year ago

We added a few TODOs about improving help files.

kcrossen commented 1 year ago

I was volunteering on an environmental education program for rural NC 4th graders. No internet, occasional cell reception. Just got reconnected yesterday. Lcn had previously requested my patience due to his preoccupation w/ Ukrainian refugees. Not entirely sure how this differs.

I also note the harsh response to my posts about JSON and CSV.

Again, my sincere gratitude for your contributions to my open source project, but we both may better stumble toward the light separately. At my age, there is crushingly inevitably so very little time left, and certainly none to waste (for either of us).

All the best, Ken

On Wed, Oct 18, 2023, 1:32 PM Landon Curt Noll @.***> wrote:

We added a few TODOs about improving help files.

Reluctantly, given a lack on direct response our questions about "protect" inheritance from @kcrossen https://github.com/kcrossen, we have removed a related calc v3 TODO.

Sadly we did not see (or somehow missed) a direct replies to our questions about the feature request. So we have put tbudren on @kcrossen https://github.com/kcrossen to code and submit changes for whatever his "protect" inheritance is via a GitHub Pull request https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request. (Click the link for GitHub pull request info).

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

pmetzger commented 1 year ago

After further consideration JIT or calc is beyond the above of calc version 3 planning. As such we have marked the JIT related comments as obsolete and removed the reference to JIT from the TODO list.

If you do ever decide to do a JIT (I don't think you should), LLVM is the right mechanism for building it these days. But I think you shouldn't.

pmetzger commented 1 year ago

Any ideas about how let calc work the gnuplot(1) / GnuPlot command would be welcome.

It would be pretty hard to do it "inline". calc is primarily a terminal based program, and gnuplot etc. generates graphics that require some sort of GUI to view even if said graphics are generated on the command line. What you could do is produce inputs for gnuplot, but one can already do that pretty straightforwardly from calc.

A much more involved project (and a very very different one indeed!) would be to create some sort of GUI notebook mode version of calc, but in that case, there's not really any advantage for calc over Jupyter with Python IMHO. What calc is great at is being a desk calculator.

pmetzger commented 1 year ago

On the question of units and dimensions: I often feel that units and dimensions are something computer systems don't often deal with well even though they should. (An exception is the language F# which added them at one point.) They're cool because, as with other sorts of types, they tell you when you've made a major mistake. I do not think Calc should add them in the near term! However, it might be a cool thing to put in "someday".

lcn2 commented 1 year ago

Any ideas about how let calc work the gnuplot(1) / GnuPlot command would be welcome.

It would be pretty hard to do it "inline". calc is primarily a terminal based program, and gnuplot etc. generates graphics that require some sort of GUI to view even if said graphics are generated on the command line. What you could do is produce inputs for gnuplot, but one can already do that pretty straightforwardly from calc.

We could see some builtin function whose default args would establish a pipe to gnuplot(1) and pump data into that pipe.

Perhaps individual values or an array could be written to such a pipe.

A "popen" related set of builtins, with a special "gnuplot" set of builtin functions, including support functions for wrtiting into the "gnuplot pipe" to make it easier to work with gnuplot(1).

Just some initial thoughts 💭.

lcn2 commented 1 year ago

On the question of units and dimensions: I often feel that units and dimensions are something computer systems don't often deal with well even though they should. (An exception is the language F# which added them at one point.) They're cool because, as with other sorts of types, they tell you when you've made a major mistake. I do not think Calc should add them in the near term! However, it might be a cool thing to put in "someday".

Fair points @pmetzger

Initially the constant sets would just be variables that were named and initialized to a given value.

A constant will not be a "C const", one will be able to change them, reload them to a new epsilon precision, free them, etc.

Theluga commented 11 months ago

Hello, I just learned about this awesome project when trying to do some calculations on my shell. (sorry for the formatting, I'm writing from my phone)

I would love to include some constants that would be really helpful on some quick checks on my use case (electrical engineering)

The vacuum permittivity ε0 could be called "elecperm0" from electric permittivity. https://en.m.wikipedia.org/wiki/Permittivity

The vacuum magnetic permeability μ0 could be called "magperm0" from magnetic permeability. https://en.m.wikipedia.org/wiki/Vacuum_permeability

And lastly the elementary charge that was cited before as e in particle physics. I believe this last one could be called "ec" as elementary charge in coulumbs. https://en.m.wikipedia.org/wiki/Elementary_charge

I think it would be good to name this way those constants, because μ (mi or mu or u) could mean friction coefficient, density etc.

As epsilon can mean a lot of things.

Thank you for your awesome work!

lcn2 commented 11 months ago

Hello, I just learned about this awesome project when trying to do some calculations on my shell. (sorry for the formatting, I'm writing from my phone)

I would love to include some constants that would be really helpful on some quick checks on my use case (electrical engineering)

The vacuum permittivity ε0 could be called "elecperm0" from electric permittivity. https://en.m.wikipedia.org/wiki/Permittivity

The vacuum magnetic permeability μ0 could be called "magperm0" from magnetic permeability. https://en.m.wikipedia.org/wiki/Vacuum_permeability

And lastly the elementary charge that was cited before as e in particle physics. I believe this last one could be called "ec" as elementary charge in coulumbs. https://en.m.wikipedia.org/wiki/Elementary_charge

I think it would be good to name this way those constants, because μ (mi or mu or u) could mean friction coefficient, density etc.

As epsilon can mean a lot of things.

Thank you for your awesome work!

Excellent ides. And useful to calculate c 🤓 if you are "so-inclined".

But seriously, these will be good to add to the physics constant set.

And thank you for your kind words, @Theluga

lcn2 commented 11 months ago

Calc v3 plans

Just an update, we are working on issue #138 (Bug: When calc is linked with and uses GNU readline then for any multi-line copy-and-paste, only the first line is executed).

There is a really "minor" memory leak relating to the random() and srandom() (the Blum-Blum-Shub pseudo-random number generator). We say "minor" because use of the Blum-Blum-Shub pseudo-random number generator does not increase the leak: it doesn't seem to grow over time, and it doesn't show up unless you use it, and the amount of memory leaked (which appears to be a constant amount when the generator is used) is small.

The Blum-Blum-Shub pseudo-random number generator seeding code in zrandom.c was made "too cleaver by half" and simply needs to be re-written to be "straightforward" implementation of seeding the generator.

For this reason we have decide to push the Blum-Blum-Shub pseudo-random number generator seed rewrite into calc v3 sp as to not delay the start of the start of the calc v3 development.

Once issue #138 has been addressed and well tested, we plan to release calc v2.15.0.5. This will be a "maintenance"-like release with the GNU readline copy-add-paste issue addressed, and a minor improvement to make clobber, plus whatever typos people manage to report in the mean time :-)

Fixing minor nits, typos and improving the calc documentation / calc man page readability is always welcome.
Nevertheless, doing this very soon, before the v3 fork, would be VERY welcome.

Once calc v2.15.0.5 as been released, we plan to use tool to normalize the calc source code in a consistent way: in similar to most of the current code. Probably the biggest change would be to go to a 4-character indentation model. None of the v3 code cleanup would be performed: just a code consistency update. Since the 1990's some part of the code were modified in a somewhat contrasting way: those sections would be bright into alignment with the majority of the rest of the code base. No calc functionality would be changed. A diff -b -w would show "nil changes" except for those "code warts" that stand out like a "sore-warty thumb".

Doing that BEFORE the fork means that if something important is discovered in the calc v3 code that needs to be back-porte into the calc v2 code branch, it will be easier to apply such a patch to the older v2 calc code. We don't anticipate making changes to calc v2, but you never know when some bug is uncovered and the fix needs to be applied to calc v2.

So after calc v2.15.0.5 we plan to do the above code wack and release (after extensive testing of course) calc v2.15.1.0. We will let that code "soak" in the wild. If all goes well, (or if a calc 2.15.1.x is needed to improve something), we will release a v2.16.0.0 as the "v3 fork point".

At present we are involved in the IOCCC (International Obfuscated C Code Contest) retooling, a year+ project to produce a better IOCCC experience. Don't worry about calc, we plan to not mimic the IOCCC winners style 🤓). That project, and the related IOCC mkiocccentry tooling has kept is very busy. The "calc v2.15.0.5" soak time will be well spent. And we will be still active in planning for the calc v3 project start.

We are excited about the calc v3 plans, and look forward to proceeding with care and solid testing and you have come to expect from calc.

As always, and in the mean time: calc v3 suggestions ideas remain welcome.

Happy 2024!

lcn2 commented 10 months ago

FYI: Issue #138 has been resolved and calc 2.15.0.5 release is now live.

As mentioned in comment 1873595215, we will now "let that code "soak" in the wild". We will continue to proceed with the above mentioned plans.

pmetzger commented 10 months ago

What tool are you using to reformat the code? clang?

lcn2 commented 10 months ago

What tool are you using to reformat the code? clang?

We are considering using the Xformat Clang Format app by Furnace Creek Software, and specifically the Xformat's Batch Format tool. And then inspect and improve if needed, by hand.

We are very open to suggestions for other tools, however.

The plan is, assuming all stays well with the most recent calc 2.15.0.5 release, we would create a calc version 2.15.1.0 out of the reformatted source code. Assuming that does well, then that would be the place where calc v2 and calc v3 fork.

pmetzger commented 10 months ago

clang-format is a command line tool bundled with clang (which is LLVM's C and C++ compiler). I haven't used it on large projects but it apparently works quite well.