accept implicit multiplication as input about algebrite HOT 7 CLOSED

can now parse the example above - can parse whenever one of the factors is a "naked" number. See tests at the commit linked in the "closure" message above.

from algebrite.

Unfortunately I’m deep in another project at the moment, I can’t look into this properly.

I think I remember that there might be some problems in supporting implicit multiplication input because it's not always unambiguous, plus I extended the language to support higher-order functions. So in (x+1)(x-1), as far as the system knows (x+1) could really result into a function to be applied to (x-1). So it can’t just assume at parse-time that (x+1)(x-1) is a multiplication. Other cases could be handled though (like in the case of numerical constants), but it could be hit and miss.

That’s as far as I remember but I might be wrong, I’d need to look into this properly to be sure 100%. Maybe try to look at the tests if there is any example that rings a bell...

How about having simplify to output with explicit multiplications instead?

from algebrite.

Thanks for your feedback.
The trouble is: simplify produces the implicit multilplication, not me. So the function expand can't be used after simplify.

from algebrite.

I think I remember that there is a flag to control that. Sorry I can't check for you as I'm deep in another project and can't "load" more code in my head right now.

from algebrite.

I'm having the same issue I think. Some Algebrite functions will return results of the form "a (y)". The implicit multiplication just before a parenthesis can't be evaluated further by Algebrite and will return "nil". My current workaround is to replace the implicit multiplication with "*":

eq.replace(/([\d\w])( )(\()/g, "$1"+"*"+"$3")

This matches any number or constant in front of a space with a start parenthesis after. It does not match "/+-" etc.

from algebrite.

Thanks @danielsvane.This is, in fact, easy to bypass. The most serious problem is a bug related with "tough" expressions, related in issue Expression too complex

from algebrite.

Great, @davidedc, thanks!

from algebrite.