From 6212bee799ad0b5350467db3a40f87baf05eb4b8 Mon Sep 17 00:00:00 2001 From: Alex Assuied <123543888+aassuied-ps@users.noreply.github.com> Date: Mon, 4 May 2026 14:37:17 +0200 Subject: [PATCH 1/8] Delete site/assign.png:sec.endpointdlp --- site/assign.png:sec.endpointdlp | Bin 1092 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 site/assign.png:sec.endpointdlp diff --git a/site/assign.png:sec.endpointdlp b/site/assign.png:sec.endpointdlp deleted file mode 100644 index 4d5c1c737f39c0787c7d508163b32a038980fad8..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1092 zcmeH{NpHeH429os>6u6g*=UYk4n1^H>5Xy-S=2}rDngMc;=lLvgbHXmR6SQ{Jf5-r z#`bgA=u9`7sn%RiTI)@fTJAE|NMmG=b*o%U6?(y1>H*)W8qRAy>K(lT!|oSY3}JzH zbA+_fGdSjDd*)=I1dNEcOZDZ;V?WnG0a~O`F}EH!K7JM21n&@Q;k=7$Nmd+=~ zFCxyOVvr2eY!>HHL*gPlykbr@dx=kq=7T$NS@oPeuK1F=X81O)F4Nmx9V2y>6+b-o zbzWgB=+i6j%|IA}^MQV^6>@R#s=d(C!716Tb%(T=zaTAlT<&AbZ&_S`-h$pS(pA0U zZc3&$16}0E?IAr%>0azkV{Ms?Et7GIRbwu7tc7%RK;IKMNOoNG9WTa3pPyL+tP@s1 zCdP@e5@5+V8($SzHHgNgahl>~tX8~Jq8ZZ>(pa?&bN9B*M(r~3UC#fk{+89RZ+^(v WK6hX8HFMg~Yn$EzdHC Date: Mon, 4 May 2026 14:37:28 +0200 Subject: [PATCH 2/8] Delete site/branch.png:sec.endpointdlp --- site/branch.png:sec.endpointdlp | Bin 622 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 site/branch.png:sec.endpointdlp diff --git a/site/branch.png:sec.endpointdlp b/site/branch.png:sec.endpointdlp deleted file mode 100644 index 23d02d196171ddc2d1b61807ec69cf6a72e4e4d1..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 622 zcmbV~PfvqD5XIkT@mvzHK$WA~g9rb_dcz(l&`3h5f!YL{es_PfG-<219(HDS=FQuE zyR*}k9@S{6wcge1OQkw;2`kkcJ7PU4(?+>IsTO(#TdQK<>rLOpB^;J-sTe~Gx;kUp z=>r}^nNOSz6vGj6cA;ze^6$TaBDOSA37I25jYYS==3Tq#Bgv{}4x=57ctr zX~lUB3^RCsh+nkDwkN0B2^}w3bGu&8SnIijX><6?V{h^27I(0Bun#{nsNRyRxv9;- o(3v_P@J2B& Date: Tue, 5 May 2026 10:08:18 +0200 Subject: [PATCH 3/8] Update Challenges.qmd Add an introduction and a plan. --- white-paper/Challenges.qmd | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/white-paper/Challenges.qmd b/white-paper/Challenges.qmd index 4920569..cc8dccb 100644 --- a/white-paper/Challenges.qmd +++ b/white-paper/Challenges.qmd @@ -1,5 +1,29 @@ # Change Management and Git -This chapter will discuss challenges in adoption of Git as well as how these might be addressed. +## Introduction +Statistical programmers in the pharmaceutical industry operate in a highly regulated environment where validated, reproducible analysis is paramount. For several years, the standard workflow has revolved around statistical computing environments managed through shared network drives, strict naming conventions, and manual version control practices (saving files with incremental version numbers or descriptive suffixes before archiving) or with regular server backups. These habits, while informal, have been deeply embedded in day-to-day practice and have served as the de facto audit trail in many organizations. +Introducing Git into this context presents a unique set of challenges that go beyond mere tool adoption. It relies on notions such as sub-branches linked to a main branch, commits, remote repositories and merges, that can be difficult to adopt for teams used to work in other environments. The learning curve can be difficult and requires to embrace a more collaborative and transparent workflow. + +Furthermore, the regulatory framework of the pharmaceutical industry is strict. Any change management system touching analysis code or submission-relevant outputs must be set in a GxP environment. Git must be used in a way that ensures theses compliances (traceability, audit, etc). + +Organizational culture also plays a significant role. Statistical programmers often work independently or in small teams with well-established personal workflows. Moving to a Git focused workflow requires not only technical training, but to being open to new mindsets and ways of working. + +## Benefits of Git for statistical programmers + +::: callout-caution +*Explain how Git can solve some issues common to all statistical programmers, such as knowing what was modified when, how to explain differences in results after an update, get a backup quickly in case of wrong manipulation/update, etc.* +::: + +## Prepare basic documentation + +::: callout-caution +*Git documentation online can be realy long and complex. Write down the basics at firs (main, sub-branches, commits, push, pull request, merge).* +::: + +## Make people use Git as a training + +::: callout-caution +*Do not demonstrate, make people use Git with small examples: make an update on a file, review a PR, read commit history, etc.* +::: From fff33d181a36af87f08a3b7d740f57c1e13b856b Mon Sep 17 00:00:00 2001 From: aassuied-ps <123543888+aassuied-ps@users.noreply.github.com> Date: Tue, 5 May 2026 10:28:04 +0200 Subject: [PATCH 4/8] Update Challenges.qmd talk about tools --- white-paper/Challenges.qmd | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/white-paper/Challenges.qmd b/white-paper/Challenges.qmd index cc8dccb..cfdc610 100644 --- a/white-paper/Challenges.qmd +++ b/white-paper/Challenges.qmd @@ -22,6 +22,13 @@ Organizational culture also plays a significant role. Statistical programmers of *Git documentation online can be realy long and complex. Write down the basics at firs (main, sub-branches, commits, push, pull request, merge).* ::: +## Introduce tools + +::: callout-caution +*Do not talk a lot about in line Git commands and show one or two software that can help (GitHub Desktop, VSCode, etc). Give command line equivalent to each actions (commit, push, etc).* +*For VSCode, since a lot of people are using SAS, RStudio or Positron, explain how to use it only for Git (or how to switch).* +::: + ## Make people use Git as a training ::: callout-caution From 00839b64108ca13675dd6a0e135fcdb3a134f078 Mon Sep 17 00:00:00 2001 From: martiki9 Date: Fri, 26 Jun 2026 14:41:29 +0100 Subject: [PATCH 5/8] some proposed changes --- white-paper/Challenges.qmd | 75 ++++++++++++++++++++++++++++++-------- white-paper/_quarto.yml | 1 + white-paper/benefits.qmd | 5 +++ white-paper/references.bib | 24 +++++++++++- 4 files changed, 88 insertions(+), 17 deletions(-) create mode 100644 white-paper/benefits.qmd diff --git a/white-paper/Challenges.qmd b/white-paper/Challenges.qmd index cfdc610..7beaa90 100644 --- a/white-paper/Challenges.qmd +++ b/white-paper/Challenges.qmd @@ -10,27 +10,70 @@ Furthermore, the regulatory framework of the pharmaceutical industry is strict. Organizational culture also plays a significant role. Statistical programmers often work independently or in small teams with well-established personal workflows. Moving to a Git focused workflow requires not only technical training, but to being open to new mindsets and ways of working. +## The Change Curve + +The Change Curve is a well known model for understanding how employees resond to change @HOLDSWORTH2024254. While there are many different implementations of it, generally speaking it is understood to be split into two main phases, first of resistance and then of acceptance. An important attitude in any company trying to make any sort of change, be it organisational or technological, is to have empathy for those individuals who are experiencing it, and give them the support they need. + +We must understand that any change will take time to embed into an organisation, and the main thing we can influence is how fast that change goes, and how well we can adopt the technology. + +In this chapter we will mostly ignore the how of using Git within your company (for more, please see the [recommendations](recommendations.qmd) chapter), and look instead about the things you can do to support your team as they learn to adopt Git in practice. + ## Benefits of Git for statistical programmers -::: callout-caution -*Explain how Git can solve some issues common to all statistical programmers, such as knowing what was modified when, how to explain differences in results after an update, get a backup quickly in case of wrong manipulation/update, etc.* -::: +One important lesson from companies that have already experienced the transition to using Git is that, because Git can be a challenging technology to adopt at first, it can be easy to lose sight as to why this change is being made. + +To combat this difficulty, we recommend highlighting early and often the benefits of adopting Git in practice. These are covered in more detail in the chapter on [benefits](benefits.qmd), but things you can easily show to someone who is learning Git: + +1) The easy audit trail on a Github repository, and the ability to view code at different points in time trivially +2) Pull Requests, and the ability to review code line by line and provide easy feedback +3) AI Integrations which can improve code review in practice +4) Findability and searchability of code + +All of these are very easy to show quite quickly, and should not be forgotten when trying to bring someone into a new technology + +## Introducing tools + +Depending on your company's size and how they want to use Git, there a number of tools to interact with Git and Github. These are covered more in the [appendix](tools.qmd), but your decision is likely to be motivated based on how close you want users to interact with Git. + +You may decide that you wish to abstract users access to Git or you might decide that you wish to get users comfortable with direct Git terminal access. Different tools will enable different approaches. + +Note that of course you are not limited to using any one tool, and can make multiple available to support different workflows and different levels of ability in your user base. The important thing when it comes to managing change is to make it clear to individuals what tools are for, and when they are using them. For consistency, it may be wise to limit teams that work together to at most two common tools. + +## Preparing Documentation + +There are a number of excellent resources for learning Git online. This means that when creating internal documentation on Git it is important to focus on how your organisation will be using Git in practice. + +Your documentation should focus first on the ways someone will work in their day to day, covering the typical flow and where possible integrating it into the tools they are likely to use. Documentation should be easy to access and use, and easy to search. We recommend where possible to not include this level of documentation in GxP training, as the latter is likely to be in systems that can be harder to update quickly based on user feedback. + +GxP training is of course important to meet our compliance requirements, but we can normally build training on top of it which enables more dyanmic updates as you get feedback from users on what works and what does not. + +### Failure cases + +An important resource to build over time is how to resolve issues that might occur when using Git. The exact nature of the issues are likely to run into will be specific to your organisations workflow but some likely common issues are + +- Merge conflicts and how to resolve them smoothly +- Undoing things (git reset and revert) +- Not being able to switch brances (git stash) + +Having simple, easy to understand guides to help in these cases can be very useful. These are things that can be taught, but don't come up frequently enough for the knowledge to necessarily be embedded, so having clear instructions on these can greatly improve Git adoption. + + +## Practical examples as training + +When teaching users to use Git, we should always focus on practical examples which relate as closely to how the user will be applying Git in practice. While for fundamentals it can be helpful to be artificial, as soon as your users have grasped the basic, we strongly encourage examples that involve practicing the workflow they do in person. + +Where possible trainings should be live, and in person if it is possible to arrange, to allow maximum engagement. + +One vital aspect is that training should be targetted only at individuals who are going to be adopting the Git workflow very soon, or who are already adopting it. This means that what they have learnt can be applied straight away, removing the danger of knowledge atrophying during use. Related to this, if you can train cohorts of users who will be working together, this can be very useful as they will be able to learn and practice together. -## Prepare basic documentation +## Feedback and checking in -::: callout-caution -*Git documentation online can be realy long and complex. Write down the basics at firs (main, sub-branches, commits, push, pull request, merge).* -::: +One important way to manage change in an organisation is to demonstrate that you are open to feedback, and responding to it. This means you must be actively seeking out feedback, not just passively waiting for it. Consider small focus groups, arranging meetings with key thought leaders, alongside regular surveys of sentiment. -## Introduce tools +When taking feedback, it is important to understand the context in which it is delivered. Try to not be too reactive: making changes immediately may not be the best course of action, but try to fully understand what the individual is saying and how you can best address it. In some cases, it may truly be that the Git workflow your organisation has chosen to adopt is not fit for purpose, but in others it may be that you need better training and support to help users address scenarios they do not currently understand. -::: callout-caution -*Do not talk a lot about in line Git commands and show one or two software that can help (GitHub Desktop, VSCode, etc). Give command line equivalent to each actions (commit, push, etc).* -*For VSCode, since a lot of people are using SAS, RStudio or Positron, explain how to use it only for Git (or how to switch).* -::: +When you do make changes based on feedback, make sure you communicate them clearly, and make clear the reason you chose to adopt them. -## Make people use Git as a training +## Conclusion -::: callout-caution -*Do not demonstrate, make people use Git with small examples: make an update on a file, review a PR, read commit history, etc.* -::: +Any kind of change can have large impacts on an organisation, and Git as a technology can definitely cause some friction. Just like with all changes, provided it is handed well and responsively, then within a few years the use of Git will simply be the new normal. diff --git a/white-paper/_quarto.yml b/white-paper/_quarto.yml index 432e2e1..9f28247 100644 --- a/white-paper/_quarto.yml +++ b/white-paper/_quarto.yml @@ -8,6 +8,7 @@ book: chapters: - index.qmd - state.qmd + - benefits.qmd - Challenges.qmd - part: "Recommendations" chapters: diff --git a/white-paper/benefits.qmd b/white-paper/benefits.qmd new file mode 100644 index 0000000..3262adb --- /dev/null +++ b/white-paper/benefits.qmd @@ -0,0 +1,5 @@ +#Benefits + +## Introduction + +This chapter aims to include at a high level some benefits for using Git in clinical development. \ No newline at end of file diff --git a/white-paper/references.bib b/white-paper/references.bib index 0220dbd..13d41a9 100644 --- a/white-paper/references.bib +++ b/white-paper/references.bib @@ -15,5 +15,27 @@ @article{knuth84 pages = {97–111}, numpages = {15} } - +@article{HOLDSWORTH2024254, +title = {From coping with dying to coping with organizational change: the bricolage of the change curve’s evolution}, +journal = {Journal of Organizational Change Management}, +volume = {38}, +number = {8}, +pages = {254-269}, +year = {2024}, +issn = {0953-4814}, +doi = {https://doi.org/10.1108/JOCM-05-2025-0479}, +url = {https://www.sciencedirect.com/science/article/pii/S0953481425000594}, +author = {Logan Holdsworth and Todd Bridgman}, +keywords = {Elisabeth Kübler-Ross, Five stages of dying, Change curve, Organizational change, Coping with change, Resistance to change}, +abstract = {Purpose +We construct an intellectual history of the change curve, a well-known model for understanding how employees respond to change, from the accepted origin point of Elisabeth Kübler-Ross’ five stages of dying model. We analyse how her model evolved from providing insight into how people cope with dying to how people cope with organizational change. +Design/methodology/approach +We mapped the evolution of Kübler-Ross’ model from its original context of psychiatry to organizational change management. We identified and analysed adaptations of the model in scholarly and practitioner literature, and assessed the implications of this evolution. +Findings +We identify three phases of the evolution of Kübler-Ross’ model – originators, transitioners and translators. These adaptations exemplify bricolage, where disparate theoretical elements are assembled based on their ability to serve the needs and interests of those developing the model. +Practical implications +We encourage practitioners to reflect critically on the strengths and limitations of the change curve. The model is relatable and offers a useful lens for exploring people’s emotional responses to change. However, it presents a universal and linear view of emotional responses, and a narrow interpretation of resistance to change. We suggest how managers might assist employees to cope with organizational change in a way more in keeping with Kübler-Ross’ original insights. +Originality/value +This is the first analysis of the evolution of Kübler-Ross’ model of dying into a well-established change management tool using the lens of bricolage. It contributes to growing interest in exploring the origins and evolution of influential management ideas.} +} From 634f13ac3cfddfff7b41e9be860bdfdc2a6eab67 Mon Sep 17 00:00:00 2001 From: martiki9 Date: Fri, 26 Jun 2026 14:44:30 +0100 Subject: [PATCH 6/8] fix stub --- white-paper/benefits.qmd | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/white-paper/benefits.qmd b/white-paper/benefits.qmd index 3262adb..5466556 100644 --- a/white-paper/benefits.qmd +++ b/white-paper/benefits.qmd @@ -1,3 +1,42 @@ +# Benefits + +## Introduction + +Statistical programmers in the pharmaceutical industry operate in a highly regulated environment where validated, reproducible analysis is paramount. For several years, the standard workflow has revolved around statistical computing environments managed through shared network drives, strict naming conventions, and manual version control practices (saving files with incremental version numbers or descriptive suffixes before archiving) or with regular server backups. These habits, while informal, have been deeply embedded in day-to-day practice and have served as the de facto audit trail in many organizations. + +Introducing Git into this context presents a unique set of challenges that go beyond mere tool adoption. It relies on notions such as sub-branches linked to a main branch, commits, remote repositories and merges, that can be difficult to adopt for teams used to work in other environments. The learning curve can be difficult and requires to embrace a more collaborative and transparent workflow. + +Furthermore, the regulatory framework of the pharmaceutical industry is strict. Any change management system touching analysis code or submission-relevant outputs must be set in a GxP environment. Git must be used in a way that ensures theses compliances (traceability, audit, etc). + +Organizational culture also plays a significant role. Statistical programmers often work independently or in small teams with well-established personal workflows. Moving to a Git focused workflow requires not only technical training, but to being open to new mindsets and ways of working. + +## Benefits of Git for statistical programmers + +One important lesson from companies that have already experienced the transition to using Git is that, because Git can be a challenging technology to adopt at first, it can be easy to lose sight as to why this change is being made. + +To combat this difficulty, we recommend highlighting early and often the benefits of adopting Git in practice. These are covered in more detail in the chapter + +## Prepare basic documentation + +::: callout-caution +*Git documentation online can be realy long and complex. Write down the basics at firs (main, sub-branches, commits, push, pull request, merge).* +::: + +## Introduce tools + +::: callout-caution +*Do not talk a lot about in line Git commands and show one or two software that can help (GitHub Desktop, VSCode, etc). Give command line equivalent to each actions (commit, push, etc).* +*For VSCode, since a lot of people are using SAS, RStudio or Positron, explain how to use it only for Git (or how to switch).* +::: + +## Make people use Git as a training + +::: callout-caution +*Do not demonstrate, make people use Git with small examples: make an update on a file, review a PR, read commit history, etc.* +::: + + + #Benefits ## Introduction From 96a229d1c006a70af3d12be60bd6eb89ab608a4b Mon Sep 17 00:00:00 2001 From: martiki9 Date: Tue, 30 Jun 2026 11:43:19 +0100 Subject: [PATCH 7/8] make benefits a stub article for now --- white-paper/benefits.qmd | 39 ------------------- white-paper/test.r | 81 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+), 39 deletions(-) create mode 100644 white-paper/test.r diff --git a/white-paper/benefits.qmd b/white-paper/benefits.qmd index 5466556..3a610f7 100644 --- a/white-paper/benefits.qmd +++ b/white-paper/benefits.qmd @@ -2,43 +2,4 @@ ## Introduction -Statistical programmers in the pharmaceutical industry operate in a highly regulated environment where validated, reproducible analysis is paramount. For several years, the standard workflow has revolved around statistical computing environments managed through shared network drives, strict naming conventions, and manual version control practices (saving files with incremental version numbers or descriptive suffixes before archiving) or with regular server backups. These habits, while informal, have been deeply embedded in day-to-day practice and have served as the de facto audit trail in many organizations. - -Introducing Git into this context presents a unique set of challenges that go beyond mere tool adoption. It relies on notions such as sub-branches linked to a main branch, commits, remote repositories and merges, that can be difficult to adopt for teams used to work in other environments. The learning curve can be difficult and requires to embrace a more collaborative and transparent workflow. - -Furthermore, the regulatory framework of the pharmaceutical industry is strict. Any change management system touching analysis code or submission-relevant outputs must be set in a GxP environment. Git must be used in a way that ensures theses compliances (traceability, audit, etc). - -Organizational culture also plays a significant role. Statistical programmers often work independently or in small teams with well-established personal workflows. Moving to a Git focused workflow requires not only technical training, but to being open to new mindsets and ways of working. - -## Benefits of Git for statistical programmers - -One important lesson from companies that have already experienced the transition to using Git is that, because Git can be a challenging technology to adopt at first, it can be easy to lose sight as to why this change is being made. - -To combat this difficulty, we recommend highlighting early and often the benefits of adopting Git in practice. These are covered in more detail in the chapter - -## Prepare basic documentation - -::: callout-caution -*Git documentation online can be realy long and complex. Write down the basics at firs (main, sub-branches, commits, push, pull request, merge).* -::: - -## Introduce tools - -::: callout-caution -*Do not talk a lot about in line Git commands and show one or two software that can help (GitHub Desktop, VSCode, etc). Give command line equivalent to each actions (commit, push, etc).* -*For VSCode, since a lot of people are using SAS, RStudio or Positron, explain how to use it only for Git (or how to switch).* -::: - -## Make people use Git as a training - -::: callout-caution -*Do not demonstrate, make people use Git with small examples: make an update on a file, review a PR, read commit history, etc.* -::: - - - -#Benefits - -## Introduction - This chapter aims to include at a high level some benefits for using Git in clinical development. \ No newline at end of file diff --git a/white-paper/test.r b/white-paper/test.r new file mode 100644 index 0000000..8125e0c --- /dev/null +++ b/white-paper/test.r @@ -0,0 +1,81 @@ +floatinginequality <- function(x, y, inequality, ...){ + compare <- isTRUE(all.equal(x,y, ...)) + if (compare){ + if (inequality %in% c("==", "<=", ">=")) return(TRUE) + return(FALSE) + } + if (inequality == "==") return(FALSE) + + if (inequality %in% c("<=", "<")) return(xy) + +} + +# Version 2: accepts an operator symbol instead of a string +# Infix operators must be wrapped in backticks: `==`, `<=`, `>=`, `<`, `>` +# Usage: floatinginequality_op(0.1+0.2, 0.3, `==`) +floatinginequality_op <- function(x, y, inequality, ...) { + op_str <- deparse(substitute(inequality)) + floatinginequality(x, y, op_str, ...) +} + +# Version 3: accepts a full expression, e.g. floatinginequality_expr(0.9 > 3*0.3) +# Self-contained: captures expression unevaluated, extracts LHS, operator, and RHS, +# then applies floating-point-safe comparison logic directly. +floatinginequality_expr <- function(expr, ...) { + e <- substitute(expr) + if (!is.call(e) || length(e) != 3) { + stop("expr must be a binary comparison expression, e.g. 0.9 > 3*0.3") + } + op <- deparse(e[[1]]) + x <- eval(e[[2]], parent.frame()) + y <- eval(e[[3]], parent.frame()) + + if (isTRUE(all.equal(x, y, ...))) { + return(op %in% c("==", "<=", ">=")) + } + if (op == "==") return(FALSE) + if (op %in% c("<=", "<")) return(x < y) + return(x > y) +} + +# Tests +cat("--- Floating point equality (would fail with naive ==) ---\n") +cat("(0.1+0.2 == 0.3) :", floatinginequality_expr(0.1+0.2 == 0.3), "\n") # TRUE +cat("(0.9 == 3*0.3) :", floatinginequality_expr(0.9 == 3*0.3), "\n") # TRUE + +cat("\n--- Strict inequality on near-equal values ---\n") +cat("(0.1+0.2 < 0.3) :", floatinginequality_expr(0.1+0.2 < 0.3), "\n") # FALSE +cat("(0.1+0.2 > 0.3) :", floatinginequality_expr(0.1+0.2 > 0.3), "\n") # FALSE +cat("(0.1+0.2 <= 0.3) :", floatinginequality_expr(0.1+0.2 <= 0.3), "\n") # TRUE +cat("(0.1+0.2 >= 0.3) :", floatinginequality_expr(0.1+0.2 >= 0.3), "\n") # TRUE +cat("(0.9 > 3*0.3) :", floatinginequality_expr(0.9 > 3*0.3), "\n") # FALSE +cat("(0.9 >= 3*0.3) :", floatinginequality_expr(0.9 >= 3*0.3), "\n") # TRUE + +cat("\n--- Clearly unequal values ---\n") +cat("(1 < 2) :", floatinginequality_expr(1 < 2), "\n") # TRUE +cat("(1 > 2) :", floatinginequality_expr(1 > 2), "\n") # FALSE +cat("(1 == 2) :", floatinginequality_expr(1 == 2), "\n") # FALSE +cat("(1 <= 2) :", floatinginequality_expr(1 <= 2), "\n") # TRUE +cat("(2 >= 1) :", floatinginequality_expr(2 >= 1), "\n") # TRUE + + +floatinginequality <- function(expr, ...) { + e <- substitute(expr) + if (!is.call(e) || length(e) != 3) { + stop("expr must be a binary comparison expression, e.g. 0.9 > 3*0.3") + } + op <- deparse(e[[1]]) + x <- eval(e[[2]], parent.frame()) + y <- eval(e[[3]], parent.frame()) + + if (isTRUE(all.equal(x, y, ...))) { + return(op %in% c("==", "<=", ">=")) + } + if (op == "==") return(FALSE) + if (op %in% c("<=", "<")) return(x < y) + return(x > y) +} + floatinginequality(0.9 >= 0.3*3) + floatinginequality(0.9 ==0.3*3) \ No newline at end of file From 2875eb0af0d0057894f78c3a3045411b277543bd Mon Sep 17 00:00:00 2001 From: martiki9 Date: Tue, 30 Jun 2026 11:43:44 +0100 Subject: [PATCH 8/8] remove erronously commited file --- white-paper/test.r | 81 ---------------------------------------------- 1 file changed, 81 deletions(-) delete mode 100644 white-paper/test.r diff --git a/white-paper/test.r b/white-paper/test.r deleted file mode 100644 index 8125e0c..0000000 --- a/white-paper/test.r +++ /dev/null @@ -1,81 +0,0 @@ -floatinginequality <- function(x, y, inequality, ...){ - compare <- isTRUE(all.equal(x,y, ...)) - if (compare){ - if (inequality %in% c("==", "<=", ">=")) return(TRUE) - return(FALSE) - } - if (inequality == "==") return(FALSE) - - if (inequality %in% c("<=", "<")) return(xy) - -} - -# Version 2: accepts an operator symbol instead of a string -# Infix operators must be wrapped in backticks: `==`, `<=`, `>=`, `<`, `>` -# Usage: floatinginequality_op(0.1+0.2, 0.3, `==`) -floatinginequality_op <- function(x, y, inequality, ...) { - op_str <- deparse(substitute(inequality)) - floatinginequality(x, y, op_str, ...) -} - -# Version 3: accepts a full expression, e.g. floatinginequality_expr(0.9 > 3*0.3) -# Self-contained: captures expression unevaluated, extracts LHS, operator, and RHS, -# then applies floating-point-safe comparison logic directly. -floatinginequality_expr <- function(expr, ...) { - e <- substitute(expr) - if (!is.call(e) || length(e) != 3) { - stop("expr must be a binary comparison expression, e.g. 0.9 > 3*0.3") - } - op <- deparse(e[[1]]) - x <- eval(e[[2]], parent.frame()) - y <- eval(e[[3]], parent.frame()) - - if (isTRUE(all.equal(x, y, ...))) { - return(op %in% c("==", "<=", ">=")) - } - if (op == "==") return(FALSE) - if (op %in% c("<=", "<")) return(x < y) - return(x > y) -} - -# Tests -cat("--- Floating point equality (would fail with naive ==) ---\n") -cat("(0.1+0.2 == 0.3) :", floatinginequality_expr(0.1+0.2 == 0.3), "\n") # TRUE -cat("(0.9 == 3*0.3) :", floatinginequality_expr(0.9 == 3*0.3), "\n") # TRUE - -cat("\n--- Strict inequality on near-equal values ---\n") -cat("(0.1+0.2 < 0.3) :", floatinginequality_expr(0.1+0.2 < 0.3), "\n") # FALSE -cat("(0.1+0.2 > 0.3) :", floatinginequality_expr(0.1+0.2 > 0.3), "\n") # FALSE -cat("(0.1+0.2 <= 0.3) :", floatinginequality_expr(0.1+0.2 <= 0.3), "\n") # TRUE -cat("(0.1+0.2 >= 0.3) :", floatinginequality_expr(0.1+0.2 >= 0.3), "\n") # TRUE -cat("(0.9 > 3*0.3) :", floatinginequality_expr(0.9 > 3*0.3), "\n") # FALSE -cat("(0.9 >= 3*0.3) :", floatinginequality_expr(0.9 >= 3*0.3), "\n") # TRUE - -cat("\n--- Clearly unequal values ---\n") -cat("(1 < 2) :", floatinginequality_expr(1 < 2), "\n") # TRUE -cat("(1 > 2) :", floatinginequality_expr(1 > 2), "\n") # FALSE -cat("(1 == 2) :", floatinginequality_expr(1 == 2), "\n") # FALSE -cat("(1 <= 2) :", floatinginequality_expr(1 <= 2), "\n") # TRUE -cat("(2 >= 1) :", floatinginequality_expr(2 >= 1), "\n") # TRUE - - -floatinginequality <- function(expr, ...) { - e <- substitute(expr) - if (!is.call(e) || length(e) != 3) { - stop("expr must be a binary comparison expression, e.g. 0.9 > 3*0.3") - } - op <- deparse(e[[1]]) - x <- eval(e[[2]], parent.frame()) - y <- eval(e[[3]], parent.frame()) - - if (isTRUE(all.equal(x, y, ...))) { - return(op %in% c("==", "<=", ">=")) - } - if (op == "==") return(FALSE) - if (op %in% c("<=", "<")) return(x < y) - return(x > y) -} - floatinginequality(0.9 >= 0.3*3) - floatinginequality(0.9 ==0.3*3) \ No newline at end of file