clarity20 / shellmath Goto Github PK

Sorry I cannot be more descriptive with the exact issue. I am short on time and just wanted to quickly try the script.

I cloned the repo and subsequently wrote the following script (the test script is located at a different path: /home/toazd/github/personal/scripts/bash/misc/sandbox):

#!/usr/bin/env bash

source /home/toazd/github/external/shellmath/shellmath.sh

_shellmath_add 1.2 2.4340 3.1234 4.234314 5.324234
_shellmath_subtract 2.4340 3.1234
_shellmath_multiply 2.4340 3.1234 4.234314 5.324234
_shellmath_divide 2.4340 3.1234

And the output after running the previous script:

$ ./shellmath1.sh
0.6894
/home/toazd/github/external/shellmath/shellmath.sh: line 484: ((: 063173158332: value too great for base (error token is "063173158332")
/home/toazd/github/external/shellmath/shellmath.sh: line 494: ((: 063173158332: value too great for base (error token is "063173158332")
/home/toazd/github/external/shellmath/shellmath.sh: line 498: ((: 063173158332: value too great for base (error token is "063173158332")
Invalid argument; decimal number required: '154.-4096516847975576672'/home/toazd/github/external/shellmath/shellmath.sh: line 742: ((: 3.1234: syntax error: invalid arithmetic operator (error token is ".1234")
0.7792789908433

For reference the answers should be (unless the order is swapped for subtract and divide - I could not find that detail in the readme):
16.315948
-0.6894 (or 0.6894)
171.391142871326
0.779278990843312 (or 1.28323746918652)

... should be short and easy because it's addition by another name.

Suggestion: In addition to the "String" and "Code" categories, set up a special "Parts" category for use with validateAndParse() that checks the integer and fractional parts. This lets us preserve most of the test cases with just a change from "String" to "Parts".

...by relaxing the constraint
        1 ≤ |s| < 10
where s is the number's significand.

Hello,
in the comments, you point out "(the "10#" operator) cannot work directly with negative numbers".

Yet $fractionalSum can become negative (line 511) and is later used (line 518 and others) with the 10# operator:

Use issue #8 to enable a calling syntax of
        _shellfloat_add mySum $x $y

... is easier now that addition is implemented. Pretty much boils down to applying the distributive law.

Hello, running a simple example I get the following error:

$ cat foo.sh
#!/bin/bash
source shellmath.sh
__shellmath_isOptimized=${__shellmath_true}
_shellmath_subtract 3.0 1.6
_shellmath_getReturnValue tmp
echo $tmp

$ ./foo.sh
shellmath.sh: line 518: ((: 10#: invalid integer constant (error token is "10#")
shellmath.sh: line 530: ((: integerSum < 0 && 10#: invalid integer constant (error token is "10#")
shellmath.sh: line 533: ((: integerSum > 0 && 10#: invalid integer constant (error token is "10#")
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is "10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is "10#")
2

$ bash --version
GNU bash, version 5.1.0(1)-release (x86_64-pc-linux-gnu)

Both + and * are implemented "head-recursively," i.e. add 1 2 3 4 expands to add 1 (add 2 (add 3 4))

This design was set up in the exigency of the moment. Its recursion depth is linear in the number of arguments.

We can improve upon this with a binary recursion: add 1 2 3 4 becomes add (add 1 2) (add 3 4)

This creates a recursion whose depth is logarithmic in the number of arguments.

Introduce a small test engine runTestCases.sh that will read testCases.sh and run the tests inside it. Then edit the tests to fit the simplified scheme and rename the file to testCases.in.

Features of the new testing scheme:

• Relieve the burden of typing out the full function names for each test by inserting _shellfloat_assert or _shellfloat where appropriate.
• Make output more informative than printing only "ok" or "FAIL":
  • Print line numbers, function names, arguments
• Introduce verbosity options to regulate this output
• Introduce option to abort at first failure

... can be tricky but I have handwritten notes and fasder's "reciprocation" to draw from.

Like the other main APIs, multiplication calls validateAndParse() twice explicitly.
It later calls addition twice. That's 4 extra calls to validateAndParse().

Tests have shown that validateAndParse() is expensive compared to the rest of the logic.

One workaround would be to have a "secret" mechanism through which multiplication can call addition without wasting clock cycles doing stuff it's already done.

Let's introduce a new calling syntax:

    _shellfloat_add  --  integerPart1  fractionalPart1  isNegative1  type1  integerPart2  fractionalPart2  isNegative2  type2

If _shellfloat_add sees the "--" argument, it will skip the calls to validateAndParse and pencil in the trailing arguments for the values that validateAndParse would have generated.

We are omitting isScientific{1,2} because they will always be FALSE in this situation.

We will have to increase the value of __shellfloat_storageSpace to accommodate the long argument list.

All the usuals:

• Function name
• Usage / invocation syntax
• Description of arguments
• Return code and/or text generated
• Verbal statement of purpose

Use a similar strategy as the TQL project: Underneath an API, write the return values (the function side effects) to the global namespace, which the caller then queries.