Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ExprTk #2825

Merged
merged 1 commit into from
Nov 14, 2024
Merged

Conversation

ArashPartow
Copy link
Contributor

@ArashPartow ArashPartow commented Nov 4, 2024

  1. Update ExprTk to 0.0.3 Release notes: https://www.partow.net/programming/exprtk/exprtk_release_notes_v0.0.3.txt
  2. Adaptor update
  3. Minor fixes and cleanups in exprtk, scalar, computed functions

@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from a8d3a1c to 0687b1d Compare November 5, 2024 05:34
@ArashPartow
Copy link
Contributor Author

ArashPartow commented Nov 5, 2024

@texodus Looks like a couple of adaptor methods and free functions need to be added to perspective::t_tscalar:

  1. to_uint64
  2. cast operator to uint64 from type

I'm ok with adding them, would you want it all in the same PR or two PRs, initially the additional adaptor methods and then this PR?

@texodus
Copy link
Member

texodus commented Nov 6, 2024

One PR would be ideal.

@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from 7658f2e to ccb4b1c Compare November 6, 2024 23:19
@texodus
Copy link
Member

texodus commented Nov 7, 2024

I'm not sure if you can see our CI logs externally, but this PR does not compile for different reasons on every architecture we support.

I have not had time to test this on anything but my development machine yet, but I've rebased your PR and fixed the local compilation errors here, which you can cherry pick.

@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch 2 times, most recently from d3ce42f to a2c2161 Compare November 7, 2024 04:06
@ArashPartow ArashPartow marked this pull request as draft November 7, 2024 04:12
@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from a2c2161 to faba9b9 Compare November 7, 2024 04:19
@ArashPartow ArashPartow marked this pull request as ready for review November 7, 2024 04:52
@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch 6 times, most recently from baebcb1 to 05e8878 Compare November 11, 2024 22:51
@ArashPartow ArashPartow marked this pull request as draft November 11, 2024 22:58
@ArashPartow
Copy link
Contributor Author

ArashPartow commented Nov 12, 2024

Finally got all the tests passing. Minor issues with some of the test results revealed a parsing issue in ExprTk.

That being said there is a change I couldn't resolve:

-    struct random : public exprtk::igeneric_function<t_tscalar> {
+    struct random final : public exprtk::igeneric_function<t_tscalar> {
         random();
-        ~random();
+       ~random();

-        t_tscalar operator()(t_parameter_list parameters);
+        t_tscalar operator()(t_parameter_list parameters) override;

         // faster unit lookups, since we are calling this lookup in a tight
         // loop.
-        static std::default_random_engine RANDOM_ENGINE;
-        static std::uniform_real_distribution<double> DISTRIBUTION;
+        std::mt19937 generator;
+        std::uniform_real_distribution<double> distribution{ 0.0, 1.0 };
     };
 -// Set up random number generator
-std::default_random_engine random::RANDOM_ENGINE = std::default_random_engine();
-std::uniform_real_distribution<double> random::DISTRIBUTION =
-    std::uniform_real_distribution<double>(0, 1);
-
-random::random() : exprtk::igeneric_function<t_tscalar>("Z") {}
+random::random()
+: exprtk::igeneric_function<t_tscalar>("Z")
+{
+    std::random_device device;
+    std::array<unsigned int,std::mt19937::state_size> seed;
+    std::generate_n(seed.data(), seed.size(), std::ref(device));
+    std::seed_seq seq(std::begin(seed), std::end(seed));
+    generator.seed(seq);
+}

It seems the use of std::random_device in a WASM/NODERAWFS context is the issue. The implementation of std::random_device is typically done by using /dev/random or /dev/urandom (at least in a posix context). However if those devices are not available, this leads to UB which resulted in spurious crashes during the js tests. I tried several approaches to getting it to work, however was not successful.

The main reason for this particular change was to properly seed the engine, as the way it is currently being setup is not correct. It will use an internal state based on whatever is in the memory contents of the allocation. Which could be random or all zeros etc.

@ArashPartow ArashPartow marked this pull request as ready for review November 12, 2024 08:24
Copy link
Member

@texodus texodus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! Looks good!

@@ -702,7 +733,7 @@ namespace details {
}

// degrees to gradians
rval.set(v.to_double() * (20.0 / 9.0));
rval.set(v.to_double() * (10.0 / 9.0));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👀

Copy link
Contributor Author

@ArashPartow ArashPartow Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the ratio for converting between degrees to grad is 1.1111...

@texodus
Copy link
Member

texodus commented Nov 13, 2024

I checked the Perspective raycasting example, which does not compile with a syntax error on this branch. It can be fixed by inserting a semicolon on line 58. I presume this was a parser error that was incorrectly accepted in 0.0.2, as we are not enabling settings_t::e_commutative_check.

@ArashPartow
Copy link
Contributor Author

I presume this was a parser error that was incorrectly accepted in 0.0.2, as we are not enabling settings_t::e_commutative_check.

Yeah that's correct, the fixes in 0.0.3 tighten up a lot of the checks - including when e_commutative_check has been disabled.

The way the parser is being configured (without e_commutative_check) currently in perspective is the best option, as the implied multiplication functionality can be surprising for people that don't come from a maple/mathematica et al. background.

@texodus
Copy link
Member

texodus commented Nov 13, 2024

I am having some trouble merging this PR. First off, GitHub's merge UI seems to timeout trying to validate it, which I've never seen before - all acceptance checks are green, but it is stuck "Checking for ability to merge automatically…".

So I tried to merge this locally and noticed my local Git client behaving strangely, e.g., there are only ~10 contemporary PRs in flight right now on the repo, but when adding yours as a remote git log suddenly decides 60+ old branches are now newer than yours, causing lineage views like this one to become unreadable. Snippet showing the git log --graph depth:

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 05e887855 (@ArashPatow/arashpartow/update_exprtk_0.0.3) Update ExprTk
| |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * a5c157ebf (@ArashPatow/arashpartow/update_exprtk_0.0.3_trials) Update ExprTk - Investigation
| |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Merging this locally (and even removing your remote) retains the date-ordering bug. Rebasing your PR on master locally and merging does not, however.

Your PR only diverges from master by 3 commits, so I'm not sure what's going on here. The date is suspicious however - Dec 31st 12:00 UTC 2023 - makes me think some metadata in the commit is corrupt or out-of order. I am not a GIT expert (clearly).

Can you please try rebasing/cherry-picking or otherwise recreating this commit on the latest master? Alternatively, I can rebase this PR locally and merge it, the commit will still carry your attribution but the GitHub PR may say "closed".

@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from 05e8878 to d66f0c8 Compare November 13, 2024 22:22
Signed-off-by: Arash Partow <partow@gmail.com>
@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from d66f0c8 to 2340bdb Compare November 13, 2024 22:22
@ArashPartow
Copy link
Contributor Author

ArashPartow commented Nov 13, 2024

@texodus I've rebased my PR to: 452bfb0eb (master) Merge pull request #2842 from finos/fix-integer-cast-function

If it still doesn't merge cleanly and without errors, I'm happy for you to cherry-pick and PR it locally and merge 👍

patch url: https://github.com/finos/perspective/commit/2340bdb85101415d4e41648211189841c727e6f0.patch

@texodus texodus merged commit e9b6cfa into finos:master Nov 14, 2024
13 checks passed
@texodus
Copy link
Member

texodus commented Nov 14, 2024

That worked, thanks!

@texodus texodus added the internal Internal refactoring and code quality improvement label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal Internal refactoring and code quality improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants