Posts: 652
Threads: 96
Joined: Apr 2022
Reputation:
22
12-10-2023, 04:46 AM
(This post was last modified: 12-10-2023, 04:47 AM by PhilOfPerth.)
Typing Print val("3*3") returns 3.
I would expect it to return 9. I don't see anything to indicate differently.
Posts: 372
Threads: 23
Joined: May 2022
Reputation:
56
12-10-2023, 04:53 AM
(This post was last modified: 12-10-2023, 05:00 AM by a740g.
Edit Reason: Fixed some typo
)
This is a rather intriguing idea. Personally, I love the idea of having an easily accessible math expression evaluator built into the language. However, Val historically has never parsed expressions. Doing this now, would be a breaking change. Perhaps we can expand Val like n = Val("3 * 3", -1), where the second optional argument would tell Val to enable the parser. No promises. Just thinking out loud.
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
It's not going to print 9 for you, as VAL doesn't do the math inside a string for you. All it does is take the string you give it -- starting from the left and moving right 1 character at a time, until it comes across an unexpected character, and then returns the value of that leading string up to that point to you.
address$ = "230 McNeil Hill Rd"
PRINT "Steve's house number is"; VAL(address$)
^ With the above, it's just going to print: "Steve's house number is 230" -- Everything after those numeric characters just get truncated and ignored.
So with your PRINT VAL("3 * 3"), it reads the leading 3. Says, "Yep! That's a number!". Reads the spaced afterwards. Says, "Nope! Not a number! The answer is 3!"
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
(12-10-2023, 04:53 AM)a740g Wrote: This is a rather intriguing idea. Personally, I love the idea of having an easily accessible math expression evaluator built into the language. However, Val historically have never parsed expressions. Doing this now, would be a breaking change. Perhaps we can expand Val like n = Val("3 * 3", -1), where the second optional argument would tell Val to enable the parser. No promises. Just thinking out loud.
Personally, I think this would be a terrible idea. Basically, you'd be moving the math evaluator which we use for CONST and applying it to Val... and I can hear the complaints already!! "Why isn't this command implemented? Why can't I do VAL ("3 * INSTR(x$, "foo")")? Or VAL("(ASC("B")")? OR....
I predict nightmares for whoever is going to try to implement such.
Instead, we should consider having a Resources folder, include the math evaluator in it, and then folks can just:
Code: (Select All) PRINT Math$("3 * 3")
'$INCLUDE:'./Resources/math_eval.bas'
Posts: 652
Threads: 96
Joined: Apr 2022
Reputation:
22
12-10-2023, 05:09 AM
(This post was last modified: 12-10-2023, 05:09 AM by PhilOfPerth.)
Yep, got it,thanks.
As usual I mised a line or two of Help that explained all of this pretty well!
But I liked Steve's idea of a Math$ function that would allow a similar result to what I wanted!
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
(12-10-2023, 05:09 AM)PhilOfPerth Wrote: Yep, got it,thanks.
As usual I mised a line or two of Help that explained all of this pretty well!
But I liked Steve's idea of a Math$ function that would allow a similar result to what I wanted!
Just plug it in! https://qb64phoenix.com/forum/showthread.php?tid=1266
Posts: 372
Threads: 23
Joined: May 2022
Reputation:
56
(12-10-2023, 05:01 AM)SMcNeill Wrote: (12-10-2023, 04:53 AM)a740g Wrote: This is a rather intriguing idea. Personally, I love the idea of having an easily accessible math expression evaluator built into the language. However, Val historically have never parsed expressions. Doing this now, would be a breaking change. Perhaps we can expand Val like n = Val("3 * 3", -1), where the second optional argument would tell Val to enable the parser. No promises. Just thinking out loud.
Personally, I think this would be a terrible idea. Basically, you'd be moving the math evaluator which we use for CONST and applying it to Val... and I can hear the complaints already!! "Why isn't this command implemented? Why can't I do VAL ("3 * INSTR(x$, "foo")")? Or VAL("(ASC("B")")? OR....
I predict nightmares for whoever is going to try to implement such.
Instead, we should consider having a Resources folder, include the math evaluator in it, and then folks can just:
Code: (Select All) PRINT Math$("3 * 3")
'$INCLUDE:'./Resources/math_eval.bas'
Now that you've said that... Yeah. The scope creep could be a disaster. This is best left to 3rd party libs.
Posts: 55
Threads: 4
Joined: Apr 2022
Reputation:
5
12-11-2023, 01:53 PM
(This post was last modified: 12-11-2023, 01:55 PM by euklides.)
"3 * 3" is an alphanumeric expression !
Val ("3 * 3") ---> 3
Val ("5 * 2") ---> 5
Val ("8 hundred dollars") ---> 8
In some old basic, this function existed: calculating an alphanumeric expression...
X=Calculate("4 * 8")---> 32
But not here in qb64
Why not yes ?
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
(12-11-2023, 01:53 PM)euklides Wrote: "3 * 3" is an alphanumeric expression !
Val ("3 * 3") ---> 3
Val ("5 * 2") ---> 5
Val ("8 hundred dollars") ---> 8
In some old basic, this function existed: calculating an alphanumeric expression...
X=Calculate("4 * 8")---> 32
But not here in qb64
It is... You just have to insert it yourself into your code: https://qb64phoenix.com/forum/showthread.php?tid=1266
Posts: 200
Threads: 5
Joined: Apr 2022
Reputation:
22
12-13-2023, 02:26 AM
(This post was last modified: 12-13-2023, 02:37 AM by JRace.
Edit Reason: *$%@# font size!
)
(12-11-2023, 01:53 PM)euklides Wrote: "3 * 3" is an alphanumeric expression !
Val ("3 * 3") ---> 3
Val ("5 * 2") ---> 5
Val ("8 hundred dollars") ---> 8
In some old basic, this function existed: calculating an alphanumeric expression...
X=Calculate("4 * 8")---> 32
But not here in qb64
That old Basic was probably interpreted. Interpreters have various evaluation functions built-in for internal use. Many interpreters are nothing but glorified evaluation functions.
With a compiled language, expressions must either be resolvable during compilation or resolved one step at a time using program code, unless you have a separate evaluation engine ala Steve's built into your program.
(Greenspun's tenth rule of programming: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.)
(In the modern day, this can be expanded to any sufficiently large program, involving any language(s).)
|