Skip to content

Conversation

@katestange
Copy link
Member

@katestange katestange commented Feb 18, 2025

By submitting this PR, I am indicating to the Numberscope maintainers that I have read and understood the contributing guidelines and that this PR follows those guidelines to the best of my knowledge. I have also read the pull request checklist and followed the instructions therein.


This should eventually resolve #518 #447 #384 #317 #539

Still to do:

  • update snapshots
  • put images in the documentation
  • there's a lag issue (?help?)
  • remove console.logs
  • go through the issues above
  • featured specimens
  • more

@katestange
Copy link
Member Author

Ok, this is far enough along to put in a draft PR. There's still a bunch to do, but I think the code is as readable as it gets for me (heavily based on turtle, which helps), and the thing works in WebGL. You can try it out if you're curious. There's one issue I'm unsure how to resolve, which is reproducible in the following way and appears to be something to do with P5GL.

  1. Open the console so you can see the console.logs
  2. Go to this url: http://localhost:5173/?name=Random+integers+0+to+9&viz=Chaos&corners=3&stepFormula=0.50009&seq=Random&last=10000&length=10001
  3. Wait for it to finish drawing -- it will log "Stopping"
  4. Then (and only then) attempt to drag the image.
  5. You'll see it log "Starting" and then it will hang for a little while. The length of the hang depends on the number of terms in the sequence it has used. After a while it will say "Starting1.5" and continue and then you can zoom and pan to your heart's content.

The catch? There's zero lines of code between console.log("Starting") and console.log("Starting1.5").

@gwhitney
Copy link
Collaborator

gwhitney commented Feb 19, 2025

Some to-do items:

the "label corners of polygon" checkbox does nothing at the moment. Weird, now it seems to be working...

  • Shouldn't the default walker to move be n % W to match the old behavior of W walkers taking turns?
  • The description string for the "Number of Walkers" says "The number w of walkers" with lower case w, but in formulas right now you have to use upper-case W to get the number of walkers. There should be consistency one way or the other.

@gwhitney
Copy link
Collaborator

2. Wait for it to finish drawing -- it will log "Stopping"

I attempted to check this issue out for you, but I never observed "Stopping" in my console, so is perhaps something else awry?

@gwhitney
Copy link
Collaborator

  1. Wait for it to finish drawing -- it will log "Stopping"

I attempted to check this issue out for you, but I never observed "Stopping" in my console, so is perhaps something else awry?

Oh, I see you commented out most of the code in that stopping section, including the console.log of "Stopping". I am observing the lag on the initial drag. But there's a lot of chatter in the console, and the console doesn't seem to be telling me much about where in the code it's freezing up. In particular, sometimes I see a last line of "Starting" while I am waiting for the lockup to end, but other times the last line is "end drawing loop 10001". And if I add a console.log of "Starting1.7" after "1.5", it seems to change the distribution of what I see. So I expect we're seeing variations in async scheduling and execution. So I am really not sure what we're waiting on before that first drag starts... But I don't think it's particularly happening at that spot in the code between Starting and Starting1.5.

@gwhitney
Copy link
Collaborator

I am not at all sure I have gotten to the bottom of this, but it seems to me that the first time that Chaos needs to execute a model() command on a given chunk, it incurs some processing time penalty -- maybe this is loading geometry information to the GPU?? -- and that penalty depends on the complexity of what is in that geometry object. I am going to push a commit, that we may want to revert mostly or completely later, that (a) reduces the chunk size to 256; (b) draws squares instead of round dots, because I am assuming they have significantly fewer vertices; and (c) every time a chunk is added, voluntarily redraws the whole thing so it has now used that chunk at least once -- the idea there is to spread out the instants at which a chunk is first used, instead of, on that first drag at the end, drawing every chunk for the first time. With these changes, I think the lag is greatly reduced -- I won't say it's gone. You can give it a whirl and see what you think, and whether you want to investigate more/more deeply, or whether you want to just go ahead with something along these lines.

I don't think the above observations really explain why Chaos seems much harder on my poor computer than Turtle, though -- and I don't think we do anything in Turtle to avoid all of the chunks being used for the first time on the first drag. Those deficiencies are a big part of why I don't think I've really gotten to the bottom of this whole thing...

If you decide to abandon pan, roll, and zoom, I wouldn't cry -- they are regular polygons anyway, so rotating is not too helpful and you can just make the vertices as spread out as possible so the image won't go off the canvas. But having made the switch to WebGL, if you want to keep it that way I am OK with it, too.

@gwhitney
Copy link
Collaborator

I was glad to see that it Just Worked to take the sierpinski triangle gallery specimen and set the step formula to 1.5 -- produces a very nice picture. Not certain whether or not steps over 1 worked before.

@gwhitney
Copy link
Collaborator

I was glad to see that it Just Worked to take the sierpinski triangle gallery specimen and set the step formula to 1.5 -- produces a very nice picture. Not certain whether or not steps over 1 worked before.

Along those lines, this makes a pretty picture: http://localhost:5173/?name=Chaos+Game&viz=Chaos&corners=3&stepFormula=max%281.7-.0001n%2C+0.5%29&seq=Random&max=2&last=13999&length=14000

The length here is chosen so that it doesn't run too long with the "standard" step value of 0.5.

@gwhitney
Copy link
Collaborator

I think in light of #541 we should just move ahead with this for alpha with an "all-formula" interface, and then after alpha, split it into its operational "pre-visualizer" and a skin that restores some of the options that have been blown away (but which behavior can be reproduced with the proper formulas), like the different coloring schemes. Question: do we need to document what options we want to restore other than via looking at the git history?

@gwhitney
Copy link
Collaborator

I think once #542 is merged this can be rebased and you can pick work back up on it as your time permits, Kate. I think the ball is in your court on this; I didn't see any outstanding review tasks on my end at the moment, but if there is something you'd like me to do, let me know.

* wip: start FormulaGrid visualizer

* feat: Prototype FormulaGrid visualizer

* feat: prototype mouseover feature of FormulaGrid

* fix: correct aspect validation

* fix: interpret any number as a color in some way or other

* fix: Typescript doesn't know abs(number) is number??

* fix: Miscellaneous UI improvements

  * Put the help-info icon for a field near its top rather than its
    bottom so that it will not move as you resize a formula input area
  * Pop the resulting help info up above all other elements so the whole
    thing is readable
  * Validate and restore color codes correctly
  * At load time and whenever there is input, auto-grow formula text areas
    if necessary to show the entire formula

* feat: mouseover text opaque, shadowed, and moves left to right

* feat: inset is formula

* fix: edge browser z-indexing

* fix: updates per review

* doc: add diagram for hexagon and plug for using it with Triangle fill order

* featured specs

* doc: triangle diagram and misc fixes

* feat: mouseover popup travels with mouse pointer, avoiding in corner

* doc,test: document and test math.triangular and inverse

* fix,test: remove async race in Scope.vue mounting, update tests

* fix: Recompute size on visualizer reset(); e.g, aspect ratio might change

* ui: placeholder for aspect

* ui: ditto for dimensions

* feat: allow placeholder to remain on input, use for dimensions/aspect

* chore: briefer formulas in featured gallery and generate example images

* doc: final polish on new doc, some formula features for it

* chore: continuous integration snapshots

* doc: fix capitalization typo

---------

Co-authored-by: Kate Stange <kstange@math.colorado.edu>
gwhitney added 6 commits April 5, 2025 09:24
* fix: linebreak long numbers (in sequence mod)

* test: breakableString & fix negative bug
* doc: update instructions for running on Mac

* doc: fix typos from review

* doc: oops more typos from review

* doc: and now make lint happy

* doc: and fix punctuation order

* doc: remove ugly space and fix lint
* test: Update snapshots for new transversal; fix a console.log

* test: Update CI snapshots
* refactor: convert Sunzi to boolean param since background has opacity

* refactor: consolidate ModFill coloring parameters

* doc: Update Fill color and Sunzi mode documentation

* chore: update GitHub CI snapshots for Fill color parameter

* feat: use rainbow colors in Woven Residues

* dummy: grab ci snapshots for updating

* test: update WovenResidues CI snapshots
gwhitney added 2 commits April 5, 2025 09:24
…cused (numberscope#552)

* fix: Don't fire FactorFence keys when an input has focus

* doc: Comment the roundabout control-event handling
* fix: Resize canvas on resize event (fix numberscope#523)

* fix: check domain as you draw, to fix numberscope#491

* feat: use ordinary axis orientation in Turtle

* chore: no new CI snapshots after all
@katestange
Copy link
Member Author

Question for the Numberscope mind: when a formula is out of bounds (e.g. the walker or corner formula outputs a walker or corner that doesn't exist), what should happen, ideally? Right now it throws a popup but that seems annoying. Is it possible to have it give an orange warning and carry on ignoring it?

@katestange
Copy link
Member Author

Another request for advice. Right now formulas can break on bigints. For example, the formula mod(a,p) where p is the number of corners, can return something that, when it goes into safeNumber, comes out larger than p. Since this isn't the user's fault (in the sense that it is reasonable to expect mod(a,p) to be at most p-1), should this be handled in some other way than faulty formulas (users putting corner formula = 10 when there are only 3 corners)? Or is this avoidable entirely?

@katestange
Copy link
Member Author

Another question. Where are we about formulas? If I have a formula that should give a corner or walker, should I be manually flooring the result?

@gwhitney
Copy link
Collaborator

gwhitney commented Apr 6, 2025

Ugh, this PR has sadly gotten into a state in which the changes GitHub is showing do not seem to correspond to the changes being made in this PR. They seem to include changes from a bunch of other PRs. That state will make it virtually impossible to review. Are you able to get it in sync, maybe with some kind of a rebase, or possibly make a new "clean" PR from ui2 with just the desired changes from this PR?

@gwhitney
Copy link
Collaborator

gwhitney commented Apr 6, 2025

Question for the Numberscope mind: when a formula is out of bounds (e.g. the walker or corner formula outputs a walker or corner that doesn't exist), what should happen, ideally? Right now it throws a popup but that seems annoying. Is it possible to have it give an orange warning and carry on ignoring it?

Turtle in "Rule mode" simply ignores entries that are not one of the values in the Domain, just as if they had not occurred in the sequence. It displays an orange warning if this happens frequently. You could behave analogously in Chaos for the walker and corner formulas.

@gwhitney
Copy link
Collaborator

gwhitney commented Apr 6, 2025

And re your questions on Formulas: nailing down the behaviors of formulas to make them really airtight is pretty much waiting on upgrading mathjs, and that is in turn stuck on a number of bugs concerning bigint handling and what formulas should do when the result of an operation lies outside the number system of its operands (e.g. the log of rational number, etc.). So my suggestion would be just to note the offending cases in the "upgrade mathjs" issue #343 and not sweat them for alpha.

@katestange
Copy link
Member Author

Superseded by #561 since there were rebase issues as usual.

@katestange katestange closed this Apr 6, 2025
@katestange katestange mentioned this pull request Apr 6, 2025
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants