I’ve looked briefly at the pattern facility in CL but feel I need a simpler example to understand what is involved. Assuming three stages, can anyone provide answers to the associated questions:
Define the pattern. If my pattern is “x(y)” how would I define that in CL?
Check a value against a pattern. For a value of “2(3)” how do I confirm that it matches the pattern?
Extract components from a value. Assuming a correct match, how do I extract the variable components “x” and “y” in this case?
…since receiving the reply from @Daniel_Wekselgreene I’ve tried out what he provided in a project that prompted the original post. I’ll give access to it in due course but, in essence, I wanted students to complete entries in a table holding initial values of the form “number(?)”, replacing each question mark with a number they have to calculate by hand. Using Daniel’s response, I have been able to do that successfully, putting up an error triangle if the final string doesn’t match the built-in product template and giving feedback in the cell suffix if the entered value is incorrect.
That solves my immediate problem but I’m afraid I’m not that much further on in my understanding of pattern use. As a first step I think it would be useful to add more to the currently brief description of templates in the documentation. For example, what are the built-in templates and what do they mean? I have now used the ‘product’ template but could I have achieved the same results with the ‘expression’ template, perhaps allowing me to insist on brackets around the entered value to avoid x*y being taken for x(y)?
The final statement in the documentation is “Patterns are a beta feature and you should use them carefully! We expect to make them easier to use over time and will be expanding our documentation as we do.”
If feedback is being invited prior to simplification, something like the following would be ideal and feels achievable:
my_pattern = patterns.template(‘x(y)’)
valid_template = my_pattern.isdefined
valid_input = my_pattern.matches(input_value) …as at present.
x = my_pattern.element(input_value,‘x’)
y = my_pattern.element(input_value,‘y’)
You’re really just arguing about syntax. What you have above is pretty much @Daniel_Wekselgreene’s solution just not your verbiage. my_pattern = patterns.template(‘x(y)’)
What is acceptable for x and y? I could say x=3y+2 or x=2 or x=pi
In the solution provided, he uses p=patterns since it gets used so often. That said,
p.product(p.number,p.number)
is a product where your x and y can only be numbers, but you could potentially have an expression, or more specifically an integer, or a fraction, or any of other variety of specifics…
p.product(p.integer, p.expression)
valid_template may just require debugging your own code as isDefined is again a little ambiguous.
The .elements are the same idea as below, but again just different syntax.
I agree that it would be helpful for the documentation to better describe pattern usage. It took me a while to feel comfortable with how they work. But if you go through the video playlist linked above, it will actually show a bunch of examples that help you see how it all works.
If you have another pattern that you’re trying to make and getting stuck with, just post that and I’ll try to help clarify.
I think the point is more about design than syntax. The key issue is how the template is defined. I’m struggling to understand how I should or could be using the built-in templates. It would be great just to supply a latex string and have Desmos interpret it; then, if it is a valid expression, be able to analyse another string against that template to confirm a match and extract the variable components.
Thanks @Daniel_Wekselgreene, I will take up your offer if I run into a similar situation. Out of curiosity, could I have used the ‘expression’ template (or the ‘scientific’ or some other) to process ‘x(y)’?
I think this is much more difficult to than you think it might be. It would also probably significantly slow down your activities. I think too it may be a little more appropriate to think of the patterns as “constraints” than “templates”. For example, patterns.expression is much broader than p.number, which is broader than p.integer. There will be incorrect solutions that slip through the cracks as you learn to use them.
My suggestion is based on seeing how mathematical expressions of any complexity can be analysed within a graph component. The implication is that there is existing code that can do most of the work needed.
When you say “process x(y)”, it depends on what answers you want to allow. If you did p.product(p.expression, p.expression) it would match 3(5), but it would also match (3x)(5x^3+2) because you are asking it to look for the product of any two expressions.
I used p.product(p.number, p.number) but that would also allow (3.5)(2.74). If I wanted to only match integers, then I would use p.integer instead of p.number.
If I wanted to match mx, where m is an integer and x is a variable, I would use p.product(p.integer, p.literal(“x”)).
Scientific will only match something in scientific notation. So if I used p.product(p.scientific, p.scientific), it would only match something like (310^4)(510^7).
Thanks @Daniel_Wekselgreene. Taking what you have said with @Daniel_Grubbs 's comments, I think I now understand the current pattern feature. Seeing it in terms of constraints rather than a template definitely helps. With more documentation I might even be able to fly solo!
I see what you’re saying, but I think that the way the graph component graphs is more akin to creating a table of values than deciphering the form of the equation.
