fernandreu / blazor-fractals Goto Github PK

The intention would then be to only publish it via the CI/CD workflow, never manually.

CORS will need to be enabled for this. The full argument list in Rider would be:

host start --port 7071 --pause-on-error --cors *

This is to simplify the ToString result. The idea is to pass an argument to determine if the parents are needed for a sum, product, power, etc. (could be an enum).

Some options:

• AWS Lambda
• Azure Functions
• A simple Asp.Net Core server

Azure Functions seems like a good fit. It could just be a simple project under the same solution which refers to the same ApplicationCore project and gets deployed at the same time as the front end.

Perhaps give the option to choose between executing the call locally or not. It would be a pity having to depend on a server just because the computation can be slow and blocks the UI thread.

This becomes especially important for derivatives, where their raw application can lead to many terms that could otherwise cancel each other.

Some possible simplifications:

• (a+b)+c === a + b + c
• (a*b)*c === a * b * c
• -(a+b+c) === -a-b-c
• (-a)*(-b) === a*b
• (-a)/(-b) === a/b

This could be its own element under Shared, being used in the index page for now but to be put later somewhere more appropriately.

This will make it easier to share images with other people.

Once this is done, add the links for each example in the README. Recreating the screenshots might be needed if parameters are not known exactly.

Remember to update the README once done.

Note that sqrt(z) and exp(z) can already be entered (but in a slower, less convenient way) as z^0.5 and E^z respectively.

Not that it works incorrectly now, but it is a bit hard-coded. Making it a bit more flexible would allow adding more operators more easily.

This would allow using advanced controls (e.g. modals) without having to use (or manage) JavaScript plugins directly, while also ensuring the underlying Bootstrap library is kept up to date.

The transition should be relatively straightforward, provided the naming convention they followed is similar to Bootstrap.

This will be especially needed when calculating derivatives, as many times the result depends on itself.

Not too critical since you can force the correct parsing by adding extra brackets (i.e. (sin(z))^2).

The Cancel button could replace the Generate one, or simply hide all controls and show an alternative panel.

Things it should do:

• Apply the Newton's method to a range of coordinates and return the results that would make the fractal image

Things it should not do (yet):

• Return a byte array directly: instead, return an intermediate object to create that array from the library. Leave the conversion to image for a second step
• Parallelize the execution

This is despite them showing in that format when too small (e.g. precision)

This could be a list of color input controls with add / remove buttons. It might be nice to be able to specify exactly which color corresponds to which root, but that will not be very practical in most situations.

This will ultimately be what gets evaluated for each pixel of the fractal. There are a few ways to parse arbitrary expressions out there, but probably none up for the task. Keep it in Expression<> form so that it can be derived later.

In fact, perhaps this should use an intermediate class structure like the original fractals application, with that class being responsible for the conversion to an Expression, or finding the derivative.

This will be a collection of settings (expression, multiplicity, options, etc.) that are known to produce nice fractals.

There should be a dropdown somewhere from where you pick one of those and all associated settings automatically change.

There are some settings that should probably not be loaded this way:

• Image size
• Colors

These could be put in a menu at the left side, similar to the one in the template. The menu could be used later for other things.

The response from the function should probably not be the image contents directly. Instead, it should be a simple structure with a success / failure status, a reason for failure if any, and then the actual image contents. This implies there should be a generic try / catch block in the function.

This would return another MathElement instance

The parallelization works well locally because the number of cores is automatically set to those of the computer. However, this seems to be limited to 2 in Azure Functions.

The alternative should be to launch each parallel execution as a separate Azure Functions call. Before that, the way this gets parallelized should be improved as well, otherwise there would be 500 calls for a 500x500 image for example.

First step should be to increase the chunk size so that only one gets run per process. Rather than stripes, these should be random portions of the image, for example rectangles. The idea is to avoid the bottleneck of having to wait for a single function just because it received the chunks requiring the most iterations.

The fan-out / fan-in pattern for Durable Functions can be used for this.

The parallelization in MathUtils could be refactored into an abstract class to be passed as an argument to the fractal method. The current code would constitute one implementation of that class, and the future Azure version would be another.

Right now, the imaginary axis is positive downwards. Not too important for a visual-only app, but it gets counter-intuitive when specifying non-centered bounds.

Probably wait until there is a bit more to talk about.

Remember to include a status badge:

Perhaps there should be a split between the build stage and the deploy stage as well

This will only be of benefit when calling the Azure Function for now. Ideas:

• The image could be divided in stripes vertically or horizontally, with each core processing one of them
• Option 1: only run in parallel the calls to the Newton method, then transform the solutions into an image in a single process
  • This should be simpler to implement, as there would be no need to synchronize anything between processes
• Option 2: do the image transformation also in parallel
  • This is ideal, but the processes will need to synchronize the solutions reached and the colors used for those. To avoid race conditions where more than one process wants to add a solution simultaneously, it might become a bottleneck
  • Perhaps have a SemaphoreSlim that is only acquired when writing a new solution / color, at which point it is checked again whether the solution exists. When simply finding a solution in there, there would be no locking, and hence no important bottlenecks

Alternatively, set up a watcher in Rider and a similar step in the workflow.

Once this is done, convert the app.css code into app.scss accordingly.

This would be similar to how GitHub shows the clone actions.

I don't see any scenario where a preemptive ToUpper / ToLower call could break anything.

Apart from the obvious usefulness of being able to show the result to the user, this will also make easier to check whether the parsed expressions are correct in tests.

It could be a ToString() override with an optional overload that accepts a parameter for the variable (z by default).

This will make it easier to decide the threshold, depth, etc.