Patterns.number and pi, e, etc

Bug Reports
1

Something’s not working the way it seems like it should.

When I …
use patterns.number to check if pi is a number, patterns thinks pi is not a number. Same thing with e

I saw …
Read above

But I expected …
patterns.number should match pi as a number since, well, it is a number.

Here’s the link to the page, dashboard, or activity:

And here are some screenshots or a video:
image

2

Thanks for the report Mike!

This isn’t a bug, just a choice made when the patterns system was designed. It’s similar to how the fraction 1/2 isn’t picked up by the number pattern, and allows authors to have finer control over how they handle inputs.

Here’s a pattern we often use in lessons to pick up a wide variety of numbers:

p = patterns

wholeNumber = p.integer
special = p.anyOf(p.literal(`\pi`), p.literal(`e`), p.literal(`\tau`))
reasonableNumber = p.product(p.optional(wholeNumber), p.optional(special))
Fraction = p.anyOf(p.fraction(reasonableNumber, wholeNumber), p.fraction(wholeNumber, reasonableNumber))

Number = p.anyOf(
  reasonableNumber, p.fraction(reasonableNumber,wholeNumber),
  p.fraction(wholeNumber, reasonableNumber),
  p.negative(special), p.negative(Fraction), p.mixedNumber,p.radical(reasonableNumber),
  p.radical(p.number), p.radical(Fraction)
)
2 Likes
3

Thanks for the detailed explanation.

For what it’s worth, a naming convention of “number” for things that aren’t numbers or vice versa is a very misleading convention.

Also for what it’s worth, that lenghty pattern you shared - and thank you for that too - fails for a number of different examples.

Considering all that, it’s not at all clear to me the purpose of this. It doesn’t result in reliable error handling and doesn’t provide fine grained control since it’s not reliable. Perhaps you could elaborate on the intent here, I think it might help others since this seems to be a fairly fundamental issue with how to treat almost every instance of number handing in patterns.

1 Like