wgxli/complex-function-plotter

feature request: allow omitted multiplication symbol "*"

Opened this issue · 4 comments

yes, i know this is prone to ambiguation and needs more care... math notations, y'know.

what i preferred is that roughly match the "copyable plain text" by wolframalpha, except the bad parts like sin^2(x) etc.

the good part here is a function call must use parenthesis.

(also since the pretty font has been added, it's another step away from code)

for reference (justification), the formula input of graphest also roughly follows this convention.

it'll be convenient if (simple but long, like series expansion) formulas copy-pasted is going to work with fewer manual tweaks.

wgxli commented

This is in principle possible. The easiest way is to make this a toggleable option, since the current plotter allows arbitrary strings as variable names. Technically you could regenerate the grammar every time the variable list is updated to always resolve strings into products of allowed variable names - but then the parsing time complexity scales badly, and some unintuitive behavior can result.

I'll implement this and see if I run into any issues.

minimum pair: ((-1)^z) (-1)^z
found when playing with: ((-1)^(-z))*(1 + (-1)^z)*(2^z - 1)*zeta(z) (-1)^(-z)*(1 + (-1)^z)*(2^z - 1)*zeta(z)
related or not, but each of these two differs. there seems to be a bug.

wgxli commented

This is due to an ambiguity: (-1)^z is actually multivalued, and the two expressions are taking different branches.

Just fixed this (choose a consistent branch for log(-1)).

in my imagination though, it might be better to provide two version for some multivalued functions like log, sqrt that behave "even"ly and "odd"ly, choosing [0,2pi) and (-pi,pi] respectively, maybe named log0 and log1? (yes there are worse ones like arccot, arcsec, ....)

and which to choose for ^ is still a problem.... at first i didn't even notice it's this pitfall though, but mathematicians (and wolframalpha output) seem to consistently use it (-1)^n but not cis or something unambiguous..."^^" for the even one? (what's worse, it collides with "real power" definition in graphest/grafeq, though being complex and analytic, we may safely ignore it.