Skip to content

Conversation

@HansOlsson
Copy link
Contributor

None of these are problematic as far I can see and currently some of them are currently needed.

Since they may delete a file there is no real discussion as far as I can see.
If we make an exception for print this could be skipped.
But I don't see any problem with changing these examples as they should be _examples_, and their side-effect is what matters.
@HansOlsson HansOlsson added L: Math Issue addresses Modelica.Math L: Mechanics.MultiBody Issue addresses Modelica.Mechanics.MultiBody labels Aug 12, 2025
@henrikt-ma
Copy link
Contributor

Looks good, but it might have been a better idea to not mix bug fixing and example enhancements in the same PR.

@HansOlsson
Copy link
Contributor Author

Looks good, but it might have been a better idea to not mix bug fixing and example enhancements in the same PR.

As far as I can tell this is just bug-fixing.

@henrikt-ma
Copy link
Contributor

I wish I could provide a review after checking this with a non-Dymola tool implementing the purity rules… Who has such a tool?

@HansOlsson
Copy link
Contributor Author

HansOlsson commented Nov 12, 2025

I wish I could provide a review after checking this with a non-Dymola tool implementing the purity rules… Who has such a tool?

To me the tool-part would primarily be to check all uses of impure to see that there no additional issues (something that should have been done when pure/impure was added). But that shouldn't block this one.

These changes one can be inspected by hand, and can easily be verified to be correct.
The issue is thus whether they in turn cause the same problem - and if so correct them. That can also be done by just looking at where they are used.

The impacts of these are:

  • Modelica.Math.FastFourierTransform.realFFTwriteToFile, used in when-algorithm in Modelica.Blocks.Math.RealFFT, Modelica.Math.FastFourierTransform.Examples.RealFFT1, Modelica.Math.FastFourierTransform.Examples.RealFFT2
  • Modelica.Math.Nonlinear.Examples.{quadratureLobatto,solveNonlinearEquations}{1,2} used in ModelicaTest.testAllFunctions and in when-algorithm in ModelicaTest.Math.TestNonlinear
  • Modelica.Math.Matrices.Examples.solveLinearEquations used in ModelicaTest.Math.TestMatricesExamplesSolveLinearEquations
  • Modelica.Math.Random.Utilities.initializeImpureRandom used for parameter-binding in Modelica.Math.Random.Examples.GenerateRandomNumbers (ok), and in initial equation in Modelica.Blocks.Noise.GlobalSeed (note: impure functions called in initial equations is allowed even if not ideal) and in initial algorithm in ModelicaTest.Math.Random.TestRandomIntegers
  • ModelicaTest.Math.colorMapToSvg in algorithm in function ModelicaTest.Math.colorMapToSvg

That lead to the following additional changes for ModelicaTest (seems I missed testing that previously):

  • ModelicaTest.testAllFunctions (not used)
  • ModelicaTest.Math.TestMatricesExamplesSolveLinearEquations (not used)
  • ModelicaTest.Math.colorMapToSvg used in when-algorithm in ModelicaTest.Math.TestColorMapToSvg, and in ModelicaTest.testAllFunctions

That should be everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

L: Math Issue addresses Modelica.Math L: Mechanics.MultiBody Issue addresses Modelica.Mechanics.MultiBody

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants