+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: Another easy one: (/showthread.php?tid=2247)
Another easy one: - PhilOfPerth - 12-10-2023
Typing Print val("3*3") returns 3.
I would expect it to return 9. I don't see anything to indicate differently.
RE: Another easy one: - a740g - 12-10-2023
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.
RE: Another easy one: - SMcNeill - 12-10-2023
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!"
RE: Another easy one: - SMcNeill - 12-10-2023
(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'RE: Another easy one: - PhilOfPerth - 12-10-2023
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!
RE: Another easy one: - SMcNeill - 12-10-2023
(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
RE: Another easy one: - a740g - 12-10-2023
(12-10-2023, 05:01 AM)SMcNeill Wrote:Now that you've said that... Yeah. The scope creep could be a disaster. This is best left to 3rd party libs.(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'
RE: Another easy one: - euklides - 12-11-2023
"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
RE: Another easy one: - SMcNeill - 12-11-2023
(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
RE: Another easy one: - JRace - 12-13-2023
(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).)