Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39394 > unrolled thread

"Adhoc?" RPN mathparser using strings instead of stack.

Back to article view | Back to comp.lang.javascript

Contents

  "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 02:46 -0800
    Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 02:56 -0800
    Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 03:10 -0800
    Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 05:40 -0800
    Re: "Adhoc?" RPN mathparser using strings instead of stack. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-01-28 08:33 -0800
      Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 10:54 -0800
        Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 10:58 -0800
          Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-29 15:12 -0800
        Re: "Adhoc?" RPN mathparser using strings instead of stack. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-01-31 10:36 +0000
          Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-31 05:09 -0800
            Re: "Adhoc?" RPN mathparser using strings instead of stack. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-01-31 18:32 +0000
              Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-31 12:36 -0800
                Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-31 12:44 -0800
              Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-31 12:52 -0800
              Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-03 13:38 -0800
          Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-11 00:01 -0800
            Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-11 00:39 -0800
            Re: "Adhoc?" RPN mathparser using strings instead of stack. "sc...@sauyet.com" <scott@sauyet.com> - 2021-02-16 08:12 -0800
              Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-16 12:33 -0800
                Re: "Adhoc?" RPN mathparser using strings instead of stack. "sc...@sauyet.com" <scott@sauyet.com> - 2021-02-17 13:28 -0800
                  Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-17 23:04 -0800
              Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-16 12:40 -0800
              Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-16 13:58 -0800
      Re: "Adhoc?" RPN mathparser using strings instead of stack. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-01-28 10:56 -0800

Page 1 of 2  [1] 2  Next page →

#39394 — "Adhoc?" RPN mathparser using strings instead of stack.

It is basicly RPN parsing, but no stack instead i break out terms to calculate and divide  string to into before string->calc string->after string.

However after the subresult calculated *correct* and joined back, it somehow lose the sign "if it is start of the current bracket/substring" that is parsed/resolved.  And i can't quite see why, the part that calculate the subresult in string call the function again until all operands in subsection exhausted. Is is recursive, well i just do not get where it lose the sign?

I do not see a way to fix it, because i do not get where i lose the sign, so i would have to restructure the function calls to solve it. If someone could explain why the sign go missing i probably could fix it.

https://jonasth.github.io/Mathparse/INDEX.HTML

[toc] | [next] | [standalone]

#39395

torsdag 28 januari 2021 kl. 11:46:30 UTC+1 skrev Jonas Thörnvall:
> It is basicly RPN parsing, but no stack instead i break out terms to calculate and divide string to into before string->calc string->after string. 
> 
> However after the subresult calculated *correct* and joined back, it somehow lose the sign "if it is start of the current bracket/substring" that is parsed/resolved. And i can't quite see why, the part that calculate the subresult in string call the function again until all operands in subsection exhausted. Is is recursive, well i just do not get where it lose the sign? 
> 
> I do not see a way to fix it, because i do not get where i lose the sign, so i would have to restructure the function calls to solve it. If someone could explain why the sign go missing i probably could fix it. 
> 
> https://jonasth.github.io/Mathparse/INDEX.HTML
Is the call structure "sort of recursive"? and that is why it is hard to debug the code. I can see it lose the sign first iteration after substring resolved.

[toc] | [prev] | [next] | [standalone]

#39396

torsdag 28 januari 2021 kl. 11:46:30 UTC+1 skrev Jonas Thörnvall:
> It is basicly RPN parsing, but no stack instead i break out terms to calculate and divide string to into before string->calc string->after string. 
> 
> However after the subresult calculated *correct* and joined back, it somehow lose the sign "if it is start of the current bracket/substring" that is parsed/resolved. And i can't quite see why, the part that calculate the subresult in string call the function again until all operands in subsection exhausted. Is is recursive, well i just do not get where it lose the sign? 
> 
> I do not see a way to fix it, because i do not get where i lose the sign, so i would have to restructure the function calls to solve it. If someone could explain why the sign go missing i probably could fix it. 
> 
> https://jonasth.github.io/Mathparse/INDEX.HTML

Do the evaluation order seem correct?

[toc] | [prev] | [next] | [standalone]

#39397

torsdag 28 januari 2021 kl. 11:46:30 UTC+1 skrev Jonas Thörnvall:
> It is basicly RPN parsing, but no stack instead i break out terms to calculate and divide string to into before string->calc string->after string. 
> 
> However after the subresult calculated *correct* and joined back, it somehow lose the sign "if it is start of the current bracket/substring" that is parsed/resolved. And i can't quite see why, the part that calculate the subresult in string call the function again until all operands in subsection exhausted. Is is recursive, well i just do not get where it lose the sign? 
> 
> I do not see a way to fix it, because i do not get where i lose the sign, so i would have to restructure the function calls to solve it. If someone could explain why the sign go missing i probably could fix it. 
> 
> https://jonasth.github.io/Mathparse/INDEX.HTML
I had nightmares about implementing a RPN parser since i actually done it "the real way" binary all the way. But when javascript offer shortcuts one will use them.

I really would appreciate if someone could take an eye upon code which reside in textarea for easy inspection.
The function that somehow change sign upon the string is 

evalSecondary(calcSTR)

This code is run after all * / is done, and take care of - +,

Basicly the function look into the "substring" after plus and minus" Iterate within substring to grip the sign and find the nearby operands  and then the perform the evaluation recursively over string in sequential order, the partial result are  joined back, and process proceed until all plus minus is exhausted.

Anyone?

[toc] | [prev] | [next] | [standalone]

#39398

On Thursday, January 28, 2021 at 4:46:30 AM UTC-6, jonas.t...@gmail.com wrote:
> It is basicly RPN parsing, but no stack [...]
> [...]
> https://jonasth.github.io/Mathparse/INDEX.HTML

Except you aren't using RPN notation...

You could have started with this this:

<https://stackoverflow.com/q/65009481/153209>

[toc] | [prev] | [next] | [standalone]

#39399

torsdag 28 januari 2021 kl. 17:33:20 UTC+1 skrev Michael Haufe (TNO):
> On Thursday, January 28, 2021 at 4:46:30 AM UTC-6, jonas.t...@gmail.com wrote: 
> > It is basicly RPN parsing, but no stack [...] 
> > [...] 
> > https://jonasth.github.io/Mathparse/INDEX.HTML 
> 
> Except you aren't using RPN notation... 
> 
> You could have started with this this: 
> 
> <https://stackoverflow.com/q/65009481/153209>
Well i like my solution, kind of layman styled, evaluate the parts needed and throw them back and keep on going.
It is probably quite how a human would do it....

But if you eyeball what make the sign dissapear i am keen to know.

[toc] | [prev] | [next] | [standalone]

#39401

torsdag 28 januari 2021 kl. 19:54:18 UTC+1 skrev Jonas Thörnvall:
> torsdag 28 januari 2021 kl. 17:33:20 UTC+1 skrev Michael Haufe (TNO): 
> > On Thursday, January 28, 2021 at 4:46:30 AM UTC-6, jonas.t...@gmail.com wrote: 
> > > It is basicly RPN parsing, but no stack [...] 
> > > [...] 
> > > https://jonasth.github.io/Mathparse/INDEX.HTML 
> > 
> > Except you aren't using RPN notation... 
> > 
> > You could have started with this this: 
> > 
> > <https://stackoverflow.com/q/65009481/153209>
> Well i like my solution, kind of layman styled, evaluate the parts needed and throw them back and keep on going. 
> It is probably quite how a human would do it.... 
> 
> But if you eyeball what make the sign dissapear i am keen to know.
Maybe i never really told my appreciation for the Javascript string functions, they are quite genious but could be made better.

[toc] | [prev] | [next] | [standalone]

#39402

torsdag 28 januari 2021 kl. 19:58:19 UTC+1 skrev Jonas Thörnvall:
> torsdag 28 januari 2021 kl. 19:54:18 UTC+1 skrev Jonas Thörnvall: 
> > torsdag 28 januari 2021 kl. 17:33:20 UTC+1 skrev Michael Haufe (TNO): 
> > > On Thursday, January 28, 2021 at 4:46:30 AM UTC-6, jonas.t...@gmail.com wrote: 
> > > > It is basicly RPN parsing, but no stack [...] 
> > > > [...] 
> > > > https://jonasth.github.io/Mathparse/INDEX.HTML 
> > > 
> > > Except you aren't using RPN notation... 
> > > 
> > > You could have started with this this: 
> > > 
> > > <https://stackoverflow.com/q/65009481/153209> 
> > Well i like my solution, kind of layman styled, evaluate the parts needed and throw them back and keep on going. 
> > It is probably quite how a human would do it.... 
> > 
> > But if you eyeball what make the sign dissapear i am keen to know.
> Maybe i never really told my appreciation for the Javascript string functions, they are quite genious but could be made better.

It seem that when string starting with minus and subtraction will be performed, that the value p-1 do not exist?
Look at -9555 string returned

When operand then used as first operand "op1" in secondary evaluation, one can suddenly not reach the value p-1.
Its nothing there?
https://jonasth.github.io/Mathparse/INDEX.HTML

[toc] | [prev] | [next] | [standalone]

#39410

On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>It is probably quite how a human would do it....
  <snip>

How a human would do it when using pencil and paper is like this :
  1 2 +
result : 3
  3 4 + 
result : 7
  /
result : 3/7 or 0.4285714285714286 depending on which style you want.

That's why, on an HP RPN calculator, you would do :
 1 2 + 3 4 + /

  John

[toc] | [prev] | [next] | [standalone]

#39411

söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris:
> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> <jonas.t...@gmail.com> wrote: 
> 
> <snip>
> >It is probably quite how a human would do it....
> <snip> 
> 
> How a human would do it when using pencil and paper is like this : 
> 1 2 + 
> result : 3 
> 3 4 + 
> result : 7 
> / 
> result : 3/7 or 0.4285714285714286 depending on which style you want. 
> 
> That's why, on an HP RPN calculator, you would do : 
> 1 2 + 3 4 + / 
> 
> John
No that is actually not how we do it ,  first we find a part of the expression that we break out to solve between clause and paragraphs, then we start doing the primary */ operations since order matter, then the secondary ones +-. This we do repeatedly until a single operand is left and we call that result.

[toc] | [prev] | [next] | [standalone]

#39413

On Sun, 31 Jan 2021 05:09:19 -0800 (PST), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

>söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris:
>> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
>> <jonas.t...@gmail.com> wrote: 
>> 
>> <snip>
>> >It is probably quite how a human would do it....
>> <snip> 
>> 
>> How a human would do it when using pencil and paper is like this : 
>> 1 2 + 
>> result : 3 
>> 3 4 + 
>> result : 7 
>> / 
>> result : 3/7 or 0.4285714285714286 depending on which style you want. 
>> 
>> That's why, on an HP RPN calculator, you would do : 
>> 1 2 + 3 4 + / 
>> 
>> John
>No that is actually not how we do it ,  first we find a part of the expression that we break out to solve between clause and paragraphs, then we start doing the primary */ operations since order matter, then the secondary ones +-. This we do repeatedly until a single operand is left and we call that result.

That's right, you look at the expression, decide what order to do the
calculations in, then do them in that order.

So, when the expression is (1 + 2)/(3 + 4) you calculate in this
order:
  1 2 +, then 3 4 +, then /
RPN!

  John

[toc] | [prev] | [next] | [standalone]

#39414

söndag 31 januari 2021 kl. 19:32:39 UTC+1 skrev John G Harris:
> On Sun, 31 Jan 2021 05:09:19 -0800 (PST), Jonas Thörnvall
> <jonas.t...@gmail.com> wrote: 
> 
> >söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris: 
> >> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> >> <jonas.t...@gmail.com> wrote: 
> >> 
> >> <snip> 
> >> >It is probably quite how a human would do it.... 
> >> <snip> 
> >> 
> >> How a human would do it when using pencil and paper is like this : 
> >> 1 2 + 
> >> result : 3 
> >> 3 4 + 
> >> result : 7 
> >> / 
> >> result : 3/7 or 0.4285714285714286 depending on which style you want. 
> >> 
> >> That's why, on an HP RPN calculator, you would do : 
> >> 1 2 + 3 4 + / 
> >> 
> >> John 
> >No that is actually not how we do it , first we find a part of the expression that we break out to solve between clause and paragraphs, then we start doing the primary */ operations since order matter, then the secondary ones +-. This we do repeatedly until a single operand is left and we call that result.
> That's right, you look at the expression, decide what order to do the 
> calculations in, then do them in that order. 
> 
> So, when the expression is (1 + 2)/(3 + 4) you calculate in this 
> order: 
> 1 2 +, then 3 4 +, then / 
> RPN! 
> 
> John
Well the result seems to come out correct now.
But there probably can be strangeness with parenthesis and signs.
I think the obvious cases is taken care  of but if someone write (8)+4 it probably crasch, but it does not make much sense to write that.
https://jonasth.github.io/Mathparse/INDEX.HTML

[toc] | [prev] | [next] | [standalone]

#39415

söndag 31 januari 2021 kl. 21:36:18 UTC+1 skrev Jonas Thörnvall:
> söndag 31 januari 2021 kl. 19:32:39 UTC+1 skrev John G Harris: 
> > On Sun, 31 Jan 2021 05:09:19 -0800 (PST), Jonas Thörnvall 
> > <jonas.t...@gmail.com> wrote: 
> > 
> > >söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris: 
> > >> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> > >> <jonas.t...@gmail.com> wrote: 
> > >> 
> > >> <snip> 
> > >> >It is probably quite how a human would do it.... 
> > >> <snip> 
> > >> 
> > >> How a human would do it when using pencil and paper is like this : 
> > >> 1 2 + 
> > >> result : 3 
> > >> 3 4 + 
> > >> result : 7 
> > >> / 
> > >> result : 3/7 or 0.4285714285714286 depending on which style you want. 
> > >> 
> > >> That's why, on an HP RPN calculator, you would do : 
> > >> 1 2 + 3 4 + / 
> > >> 
> > >> John 
> > >No that is actually not how we do it , first we find a part of the expression that we break out to solve between clause and paragraphs, then we start doing the primary */ operations since order matter, then the secondary ones +-. This we do repeatedly until a single operand is left and we call that result. 
> > That's right, you look at the expression, decide what order to do the 
> > calculations in, then do them in that order. 
> > 
> > So, when the expression is (1 + 2)/(3 + 4) you calculate in this 
> > order: 
> > 1 2 +, then 3 4 +, then / 
> > RPN! 
> > 
> > John
> Well the result seems to come out correct now. 
> But there probably can be strangeness with parenthesis and signs. 
> I think the obvious cases is taken care of but if someone write (8)+4 it probably crasch, but it does not make much sense to write that. 
> https://jonasth.github.io/Mathparse/INDEX.HTML
But i think the problems that can still be raised will be pre formatting ones.

[toc] | [prev] | [next] | [standalone]

#39416

söndag 31 januari 2021 kl. 19:32:39 UTC+1 skrev John G Harris:
> On Sun, 31 Jan 2021 05:09:19 -0800 (PST), Jonas Thörnvall
> <jonas.t...@gmail.com> wrote: 
> 
> >söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris: 
> >> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> >> <jonas.t...@gmail.com> wrote: 
> >> 
> >> <snip> 
> >> >It is probably quite how a human would do it.... 
> >> <snip> 
> >> 
> >> How a human would do it when using pencil and paper is like this : 
> >> 1 2 + 
> >> result : 3 
> >> 3 4 + 
> >> result : 7 
> >> / 
> >> result : 3/7 or 0.4285714285714286 depending on which style you want. 
> >> 
> >> That's why, on an HP RPN calculator, you would do : 
> >> 1 2 + 3 4 + / 
> >> 
> >> John 
> >No that is actually not how we do it , first we find a part of the expression that we break out to solve between clause and paragraphs, then we start doing the primary */ operations since order matter, then the secondary ones +-. This we do repeatedly until a single operand is left and we call that result.
> That's right, you look at the expression, decide what order to do the 
> calculations in, then do them in that order. 
> 
> So, when the expression is (1 + 2)/(3 + 4) you calculate in this 
> order: 
> 1 2 +, then 3 4 +, then / 
> RPN! 
> 
> John
Some simple equation solving and graphing next.

[toc] | [prev] | [next] | [standalone]

#39429

söndag 31 januari 2021 kl. 19:32:39 UTC+1 skrev John G Harris:
> On Sun, 31 Jan 2021 05:09:19 -0800 (PST), Jonas Thörnvall
> <jonas.t...@gmail.com> wrote: 
> 
> >söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris: 
> >> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> >> <jonas.t...@gmail.com> wrote: 
> >> 
> >> <snip> 
> >> >It is probably quite how a human would do it.... 
> >> <snip> 
> >> 
> >> How a human would do it when using pencil and paper is like this : 
> >> 1 2 + 
> >> result : 3 
> >> 3 4 + 
> >> result : 7 
> >> / 
> >> result : 3/7 or 0.4285714285714286 depending on which style you want. 
> >> 
> >> That's why, on an HP RPN calculator, you would do : 
> >> 1 2 + 3 4 + / 
> >> 
> >> John 
> >No that is actually not how we do it , first we find a part of the expression that we break out to solve between clause and paragraphs, then we start doing the primary */ operations since order matter, then the secondary ones +-. This we do repeatedly until a single operand is left and we call that result.
> That's right, you look at the expression, decide what order to do the 
> calculations in, then do them in that order. 
> 
> So, when the expression is (1 + 2)/(3 + 4) you calculate in this 
> order: 
> 1 2 +, then 3 4 +, then / 
> RPN! 
> 
> John
I try to fix remaining bugs, but get error messages i do not understand can't the result from eval be treated as a string?
subResult=eval(sign+op1+operand+sign2+op2);
console.log(subResult); // 431937001980
	console.log(subResult.charCodeAt(0));//Not ok?
	if(subResult.charCodeAt(0)>47 && subResult.charCodeAt(0)<58) {subResult="+"+subResult;}//Not ok?

[toc] | [prev] | [next] | [standalone]

#39454

söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris:
> On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> <jonas.t...@gmail.com> wrote: 
> 
> <snip>
> >It is probably quite how a human would do it....
> <snip> 
> 
> How a human would do it when using pencil and paper is like this : 
> 1 2 + 
> result : 3 
> 3 4 + 
> result : 7 
> / 
> result : 3/7 or 0.4285714285714286 depending on which style you want. 
> 
> That's why, on an HP RPN calculator, you would do : 
> 1 2 + 3 4 + / 
> 
> John
I finally think i got the signs  and parenthesis handling correct. I hope it handle all ordinary operators correct now.
Thanks for the interest John, sometimes it is just that needed to get the motivation.
https://jonasth.github.io/Mathparse/INDEX.HTML
Maybe some exponentiation and roots next.

[toc] | [prev] | [next] | [standalone]

#39455

torsdag 11 februari 2021 kl. 09:01:18 UTC+1 skrev Jonas Thörnvall:
> söndag 31 januari 2021 kl. 11:37:01 UTC+1 skrev John G Harris:
> > On Thu, 28 Jan 2021 10:54:10 -0800 (PST), Jonas Thörnvall 
> > <jonas.t...@gmail.com> wrote: 
> > 
> > <snip> 
> > >It is probably quite how a human would do it.... 
> > <snip> 
> > 
> > How a human would do it when using pencil and paper is like this : 
> > 1 2 + 
> > result : 3 
> > 3 4 + 
> > result : 7 
> > / 
> > result : 3/7 or 0.4285714285714286 depending on which style you want. 
> > 
> > That's why, on an HP RPN calculator, you would do : 
> > 1 2 + 3 4 + / 
> > 
> > John
> I finally think i got the signs and parenthesis handling correct. I hope it handle all ordinary operators correct now. 
> Thanks for the interest John, sometimes it is just that needed to get the motivation. 
> https://jonasth.github.io/Mathparse/INDEX.HTML 
> Maybe some exponentiation and roots next.
Try to break it, and see if it goes wrong..

[toc] | [prev] | [next] | [standalone]

#39486

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:

> I finally think i got the signs and parenthesis handling correct. I 
> hope it handle all ordinary operators correct now. Thanks for the 
> interest John, sometimes it is just that needed to get the motivation.
>
> https://jonasth.github.io/Mathparse/INDEX.HTML 
>
> Maybe some exponentiation and roots next.


That seems like a lot of code for what is not that difficult a problem.

Dijkstra's Shunting Yard Algorithm [sy] describes how to convert an
infix expression to RPN, and an RPN interpreter is trivial.  But if
you want to do this by reducing subexpressions until you have only a
single value, that's not too difficult either.  Regular expressions
will make this easy.  (And no, mathematical expressions do not form
a regular language, so no single regex will make this possible, but
recursive calls with regex allow us to do so.)

There are many examples around.  I wrote one in answer to a question
on StackOverflow [so].  That version parsed only integers, but it's
a fairly minor change to add decimals, which I posted to a GitHub 
Gist [gi].  It looks like this:

```
const evalNumericExpr = (() => {
  const ops = [
    [   // grouping
      /\(([^()]+)\)/,
      (evaluator, subexpr) => evaluator(subexpr)
    ], [ //exponentiation
      /([-+]?\d+(?:\.\d+)?)\s*[\^]\s*([-+]?\d+(?:\.\d+)?)([^\^]*)$/,
      (_, base, exp, rest) => `${base ** exp}${rest}`
    ], [ // multiplication, division, remainder
      /([-+]?\d+(?:\.\d+)?)\s*([*%\/])\s*([-+]?\d+(?:\.\d+)?)/, 
      ((ops) => ((_, a, op, b) => ops [op] (Number (a), Number (b))))(
        {'*': (a, b) => a * b, '/': (a, b) => a / b, '%': (a, b) => a % b}
      )
    ], [ // addition, subtraction
      /([-+]?\d+(?:\.\d+)?)\s*([+-])\s*([-+]?\d+(?:\.\d+)?)/,
      ((ops) => ((_, a, op, b) => ops [op] (Number (a), Number (b))))(
        {'+': (a, b) => a + b, '-': (a, b) => a - b}
      )
    ]
  ]
  const evaluator = (expr) => Number(ops .reduce(
    (expr, [regex, fn]) => regex .test (expr) 
      ? evaluator(expr .replace (
          regex, 
          (...args) => fn (evaluator, ...args .slice (1))
        )) 
      : expr,
    expr
  ))
  return evaluator
})()
```

The evaluator function uses the `ops` array of regex/replacement-function
pairs to process our expressions in the proper order.  Note that whenever 
it finds a match, it does a regex replace and then recursively calls 
itself on the result.  When it doesn't, it returns the expression 
intact.  In the end, it casts the result to a Number; a more robust 
version would report an error if that result was not numeric.  That 
wouldn't be hard to add.

We process the string, first (recursively) evaluating anything in the
innermost parentheses, then the next layer out, and so forth until
there are no more parentheses.  The trickiest thing here is that we
pass the evaluator function into the regex `replace` call.  It's
necessary since we can't simply eliminate the parentheses.  That means
that the evaluator is passed to all the replace calls.  The others
simply ignore it, as it's unnecessary there.

Then we handle exponentiation.  This is slightly different from the
multiplication, division, remainder, addition, and subtraction calls,
since exponentiation is right-associative.  So our regular expression
tests that it's working with the last `^` in our substring before
proceeding.  If we find an expression of the form

    <number> ^ <number> <remainder containing no `^` characters>

then we convert it into 

    <first ** second> <rest>

And now we recur.  Thus, we would call with the following expressions

    2 ^ 3 ^ 2 + 3 ^ 3 * 2
    2 ^ 3 ^ 2 + 27 * 2
    2 ^ 9 + 27 * 2
    512 + 27 * 2

before we moved off the exponentiation operator and moved to the
next priority ones: multiplication, division and remainder.

These are left associative.  We group them together because we can
just run them left-to-right.  The replacement function is generated
by an immediately invoked function expression (IIFE) which passes
separate callback functions for the three operations.  This is
syntactically slightly more complex than the grouping or exponentiation
cases, but it simply finds any

    <number> <op> <number>
    
where `op` is `*`, `/`, or `%`, and replaces it with the result of 
calling the appropriate operation on the two numbers.

Then the addition and subtraction works exactly the same way.

Note that the first parameter to all the replace functions except the
parentheses one is `_`.  This is a convention adopted from the syntax
many other languages offer for a parameter supplied but not used.  We
have need for the evaluator argument only in the parentheses operation.

----------

To handle your format, with implicit multiplication of parenthesized
groupings, and -- very oddly -- allowing spaces between digits, we 
can wrap it up like this:

```
const parse = (str) =>
  evalNumericExpr (str.replace(/\s/g, '').replace(/(\d|\))\(/g, '$1*('))

parse('77(3(6 -  2*3 0)(-9555+8333-5578*43453-9*12+8-91*74)/ 7)')
//=> 431937001980
```

which simply removes all spaces and adds explicit multiplication in
place of the implicit version before calling the function above.

----------

I find this quite a bit simpler than the 250 lines of JS in your 
calculator.  Honestly, I tried for a short while to follow them, but
gave up.  I have a hard time following what your overall logic is.  


  -- Scott

  [gi]: https://gist.github.com/CrossEye/841b7d0ffe83c6e9e9d5c44458e5377a
  [so]: https://stackoverflow.com/a/59329911/1243641
  [sy]: https://en.wikipedia.org/wiki/Shunting-yard_algorithm

[toc] | [prev] | [next] | [standalone]

#39488

tisdag 16 februari 2021 kl. 17:12:54 UTC+1 skrev sc...@sauyet.com:
> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> 
> > I finally think i got the signs and parenthesis handling correct. I 
> > hope it handle all ordinary operators correct now. Thanks for the 
> > interest John, sometimes it is just that needed to get the motivation. 
> > 
> > https://jonasth.github.io/Mathparse/INDEX.HTML 
> > 
> > Maybe some exponentiation and roots next.
> That seems like a lot of code for what is not that difficult a problem. 
> 
> Dijkstra's Shunting Yard Algorithm [sy] describes how to convert an 
> infix expression to RPN, and an RPN interpreter is trivial. But if 
> you want to do this by reducing subexpressions until you have only a 
> single value, that's not too difficult either. Regular expressions 
> will make this easy. (And no, mathematical expressions do not form 
> a regular language, so no single regex will make this possible, but 
> recursive calls with regex allow us to do so.) 
> 
> There are many examples around. I wrote one in answer to a question 
> on StackOverflow [so]. That version parsed only integers, but it's 
> a fairly minor change to add decimals, which I posted to a GitHub 
> Gist [gi]. It looks like this: 
> 
> ``` 
> const evalNumericExpr = (() => { 
> const ops = [ 
> [ // grouping 
> /\(([^()]+)\)/, 
> (evaluator, subexpr) => evaluator(subexpr) 
> ], [ //exponentiation 
> /([-+]?\d+(?:\.\d+)?)\s*[\^]\s*([-+]?\d+(?:\.\d+)?)([^\^]*)$/, 
> (_, base, exp, rest) => `${base ** exp}${rest}` 
> ], [ // multiplication, division, remainder 
> /([-+]?\d+(?:\.\d+)?)\s*([*%\/])\s*([-+]?\d+(?:\.\d+)?)/, 
> ((ops) => ((_, a, op, b) => ops [op] (Number (a), Number (b))))( 
> {'*': (a, b) => a * b, '/': (a, b) => a / b, '%': (a, b) => a % b} 
> ) 
> ], [ // addition, subtraction 
> /([-+]?\d+(?:\.\d+)?)\s*([+-])\s*([-+]?\d+(?:\.\d+)?)/, 
> ((ops) => ((_, a, op, b) => ops [op] (Number (a), Number (b))))( 
> {'+': (a, b) => a + b, '-': (a, b) => a - b} 
> ) 
> ] 
> ] 
> const evaluator = (expr) => Number(ops .reduce( 
> (expr, [regex, fn]) => regex .test (expr) 
> ? evaluator(expr .replace ( 
> regex, 
> (...args) => fn (evaluator, ...args .slice (1)) 
> )) 
> : expr, 
> expr 
> )) 
> return evaluator 
> })() 
> ``` 
> 
> The evaluator function uses the `ops` array of regex/replacement-function 
> pairs to process our expressions in the proper order. Note that whenever 
> it finds a match, it does a regex replace and then recursively calls 
> itself on the result. When it doesn't, it returns the expression 
> intact. In the end, it casts the result to a Number; a more robust 
> version would report an error if that result was not numeric. That 
> wouldn't be hard to add. 
> 
> We process the string, first (recursively) evaluating anything in the 
> innermost parentheses, then the next layer out, and so forth until 
> there are no more parentheses. The trickiest thing here is that we 
> pass the evaluator function into the regex `replace` call. It's 
> necessary since we can't simply eliminate the parentheses. That means 
> that the evaluator is passed to all the replace calls. The others 
> simply ignore it, as it's unnecessary there. 
> 
> Then we handle exponentiation. This is slightly different from the 
> multiplication, division, remainder, addition, and subtraction calls, 
> since exponentiation is right-associative. So our regular expression 
> tests that it's working with the last `^` in our substring before 
> proceeding. If we find an expression of the form 
> 
> <number> ^ <number> <remainder containing no `^` characters> 
> 
> then we convert it into 
> 
> <first ** second> <rest> 
> 
> And now we recur. Thus, we would call with the following expressions 
> 
> 2 ^ 3 ^ 2 + 3 ^ 3 * 2 
> 2 ^ 3 ^ 2 + 27 * 2 
> 2 ^ 9 + 27 * 2 
> 512 + 27 * 2 
> 
> before we moved off the exponentiation operator and moved to the 
> next priority ones: multiplication, division and remainder. 
> 
> These are left associative. We group them together because we can 
> just run them left-to-right. The replacement function is generated 
> by an immediately invoked function expression (IIFE) which passes 
> separate callback functions for the three operations. This is 
> syntactically slightly more complex than the grouping or exponentiation 
> cases, but it simply finds any 
> 
> <number> <op> <number> 
> 
> where `op` is `*`, `/`, or `%`, and replaces it with the result of 
> calling the appropriate operation on the two numbers. 
> 
> Then the addition and subtraction works exactly the same way. 
> 
> Note that the first parameter to all the replace functions except the 
> parentheses one is `_`. This is a convention adopted from the syntax 
> many other languages offer for a parameter supplied but not used. We 
> have need for the evaluator argument only in the parentheses operation. 
> 
> ---------- 
> 
> To handle your format, with implicit multiplication of parenthesized 
> groupings, and -- very oddly -- allowing spaces between digits, we 
> can wrap it up like this: 
> 
> ``` 
> const parse = (str) => 
> evalNumericExpr (str.replace(/\s/g, '').replace(/(\d|\))\(/g, '$1*(')) 
> 
> parse('77(3(6 - 2*3 0)(-9555+8333-5578*43453-9*12+8-91*74)/ 7)') 
> //=> 431937001980 
> ``` 
> 
> which simply removes all spaces and adds explicit multiplication in 
> place of the implicit version before calling the function above. 
> 
> ---------- 
> 
> I find this quite a bit simpler than the 250 lines of JS in your 
> calculator. Honestly, I tried for a short while to follow them, but 
> gave up. I have a hard time following what your overall logic is. 
> 
> 
> -- Scott 
> 
> [gi]: https://gist.github.com/CrossEye/841b7d0ffe83c6e9e9d5c44458e5377a 
> [so]: https://stackoverflow.com/a/59329911/1243641 
> [sy]: https://en.wikipedia.org/wiki/Shunting-yard_algorithm

Yeah i have no doubt your code work, but it seem to require you to be fluent with regexp, to a degree that probably take many years to achieve.
But i noticed within at least chrome eval actually do evaluate full expressions. So basicly your code and my code was for nothing, well unless you wan't it to do bignumberss which i do not think eval support.
So that is my next thing replace eval with my own functions doing bignumbs, and maybe some optimisation, not reading string from beginning after insertion and also doing the adds in one swoop "within subregion".

But i was surprised eval did handle brackets and parsed correctly even the implicit multiplication. But it do not like the spaces....

[toc] | [prev] | [next] | [standalone]

#39491

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:
> Scott Sauyet <scott@sauyet.com> wrote:

>> [... code captured at 
>>  https://gist.github.com/CrossEye/841b7d0ffe83c6e9e9d5c44458e5377a ]


> Yeah i have no doubt your code work, but it seem to require you to 
> be fluent with regexp, to a degree that probably take many years to 
> achieve.

Well, no, it involves fairly basic knowledge of regex, which I would
expect all intermediate developers to have and many beginners too.

Two hours with a regex tutorial would probably be enough.


> But i noticed within at least chrome eval actually do evaluate full
> expressions. So basicly your code and my code was for nothing, well 
> unless you wan't it to do bignumberss which i do not think eval support. 


    eval('123456789123456789123456789n + 876543210876543210876543210n')
    //=> 999999999999999999999999999

But wait, you wrote all this because you didn't think `eval` would 
work?  Really?!  Do you know what `eval` is for?  The point is to 
evaluate a string as though its content was a snippet of source code.

I can't imagine a numeric expression that you could write in your JS
source file that `eval` couldn't evaluate.

I had assumed that you did this because you didn't want to use `eval`.
There are plenty of reasons to take that point of view, and I've written
many complex functions to avoid `eval`.  But you simply wanted those
results and didn't mind `eval` and you didn't even test it?  Something
is off.


> But [`eval` does] not like the spaces....

Well spaces between the digits of a number is a very odd concept.  The
other spaces in your expression should not cause an issue. 


> Well my code is quite simple, it finds subsegments and resolve them, 
> and put them back into string.



> Not a regexp in sight, so the learning curve is zero LoL.

Well, I'm an experienced developer who spent maybe 15 minutes with it,
and did not understand it, so I expect there is a learning curve.  But
I see that you've since deleted it from the web, so... best of luck.

  -- Scott

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web