Re: Extended PEMDAS.
Re: Extended PEMDAS. You can use functions and classes in Python in any order, so long as you don't do it at the top level. Something like this is fine:def a(): return b() def b(): return 5It's only a problem with variables, and only in the context in which they are defined. Even this is okay:def f(): return my_global my_global = 5So it's not like there's not precedence for this kind of thing. URL: https://forum.audiogames.net/post/619523/#p619523 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. @Chris Norman ok so this is pretty interesting. I became a little curious of what a parser combinator library API looks like in python, so I started reading the landing page for parsita and read the following paragraph"In a technique that I think is new to Python, Parsita uses metaclass magic to allow for forward declarations of values. This is important for parser combinators because grammars are often recursive or mutually recursive, meaning that some components must be used in the definition of others before they themselves are defined."so that particular "magic" you talked about is probably in every parser library in python. but, if I could try to explain, I don't think having forward declarations is as magical as it first seems. at least I don't think it should keep you up at night.I think the issue is that python, probably due to being a scripting language doesn't really support forward declarations without some magic, so seeing them must be quite weird. as a scripting language, the top level statements of the file can make up an actual program, whereas in non-scripting languages, which generally means compiled languages, the entry point needs to be wrapped in a main function, as the top level entities can only be functions and variables like for C and Haskell. or classes, interfaces, etc. for something like Java.for python and other interpreted languages (as far as I am aware) top level entities become alive line by line as they are interpreted. in compiled languages, all the top level entities are born at the same time, at compile time, so they don't have this awkward phase were some top level things have been declared and some haven't.In these languages having a mutually dependent declaration is totally fine and non magical. like this in Haskell. same can be expressed in C, Java, etc.data Employee = Employee Managerdata Manager = Manager [Employee]the same cannot be expressed in python without magic. following code throws error:class Employee: manager: Managerclass Manager: employees: list[Employee]this example is a little contrived, but there are instances where two declarations utually depend on one another, so python has to employ some magic to make it work. I remember in Django, if you have two Models that rely on one another, then if you need to refer to one before it is declared, you can use a string instead of the class and django will make it work.so I am afraid your fork is probably literally impossible, since the reason they employ "magic" to use something that hasn't been declared yet is there because it is necessary. but hopefully this post has given you some idea why this sort of thing isn't anything that magical at least in the context of pretty much any compiled language. URL: https://forum.audiogames.net/post/619510/#p619510 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. Yeah, a parser combinator lib might play well with mypy, as long as mypy etc. don't freak out at insane operator overloading and there's a type definition for it. URL: https://forum.audiogames.net/post/619440/#p619440 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. @12 I think you might be interested in trying out a parser combinator library. I haven't used any in python, but I have used them for Elm and Haskell, and they are totally non-magical and one of their major strengths is their strong typing, which really helps you figure out whether your parser logic actually makes any sense before you even run it. I see there are some python libraries that follow the same design like Parsec and Parsita. again I haven't tested them, but it might be worth checking something like that next time. hopefully there is a parser combinator library in python with good type hints as wellthere can be issues with performance when if you deal with a backtracking parser, so you need to take care there since if you put together two parsers with backtracking in two different ways that give you the same result can have drastically different performance profiles. also at least from my experience from Haskell parser combinator libraries, performance varies quite a bit, so when finding one in python I would assume you would also need to be careful in choosing one if performance is key. although even the slowest libraries are still fine if you aren't developing some web service where throughput is #1 metric and parsing is the major bottleneck URL: https://forum.audiogames.net/post/619375/#p619375 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. @12I can't find the docs on that quickly, but with Ply the tokens list is single quoted. Are you sure that's not single quoted as well?I get where you're coming from on wanting this to play nice with things like mypy, but you won't get what you want if you go down this road. Just leave it alone. Even the C/C++ libraries for this don't play nice with the tooling for C/C++. You can't have both a non-magical parsing tool/library *and* be able to write complex parsers at the same time. The magical docstrings are like half the point, because they let you write EBNF syntax, which then gets compiled to even more magical internal data structures.if you'd written a programming language or two I would be like meh whatever, but you probably don't understand the problem space. Also, the generated parsers that these put out and the internal data structures they build are complicated enough that I consider them hard and I don't claim to fully understand the problem space either despite doing quite a bit with this sort of stuff in college for a semester, for perspective. I understand that what you want to do seems like a great idea, but it's not. I'd say 50-50 that your fork ends up buggy in subtle enough ways that you don't notice for months, while being quite ugly for complex cases. You can just do boring old unverified Python for your parser, which should overall be very boring code-wise anyway, then process whatever it spits out somewhere else. URL: https://forum.audiogames.net/post/619224/#p619224 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS.
@8It's not the complexity I have an issue with, it's lines like:symbols = {lparent, rparent, plus, minux, multiply, divide}I'm not sure how they're doing it, but those entries aren't defined yet, so they should raise a syntax error.Also, ply uses docstrings to give you the BNF for the parser portion, and SLY uses a horrible _ decorator, which isn't defined, so linters have a fit. I want either a decorator, or a list of symbols, not both.
URL: https://forum.audiogames.net/post/619194/#p619194
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. If you have 5d6 then you have to generate 5 uniformly distributed random integers between 1 and 6, then sum. This isn't mathematically equivalent to generating an integer between 1 and 30 because reasons that I can't do the proof for offhand anymore and also it needs calculus or something to do said proof.It's not complicated, just a simple for loop. But if you're going to do really complicated expressions like this in a loop for a game or something and they're going to be all over, that gets slow even in C++ and you'll want to look into more efficient approximations, or adopting a random number generator like xoroshiro. But that's probably way beyond anything you want to do here. URL: https://forum.audiogames.net/post/619114/#p619114 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. @9, that's actually a good point. So you're suggesting randomizing each seperately? Probably wouldn't be that big of a deal. URL: https://forum.audiogames.net/post/619111/#p619111 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. Hey regarding the randomization of the dice result (that is using a random number between the minimum and maximum possible dice roll), you should avoid doing that. This is because it changes the probability distribution of the results.For example say you rolled 2d6. The minimum is 2 (1+1) and the maximum is 12 (6+6). So you then have an equal chance of rolling a number between 2 and 12 (1/11), however that isn't how the roll would play out for a real pair of dice. URL: https://forum.audiogames.net/post/619094/#p619094 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. Hey regarding the randomization of the dice result (that is using a random number between the minimum and maximum possible dice roll), you should avoid doing that. This is because it changes the probability distribution of the results.For example say you rolled 2d6. The minimum is 2 (1+1) and the maximum is 12 (6+6). So you then have an equal chance of rolling a number between 2 and 12 (1/11), however that isn't how the roll would play out for a pair of dice. URL: https://forum.audiogames.net/post/619094/#p619094 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. You may wish to check these out:This is a really good intro on parsing. I know people suggest using external libraries, but I'd implement one myself first to see how it all works. You'll learn much more doing so.The next two chapters also may give insights into how to structure your expressions. They build an AST (Abstract Syntax Tree), which is what the examples in post 3 are, just without the fancy class representations. Obviously you have a much simpler goal -- constructing a basic calculator -- but all you'd have to do is reduce the tokens you scan for.This serves as a good introduction, and perhaps a summary, of the first resource. Where the first source discusses it with you, guiding your thoughts along the way, the second is more didactic: "Here's what you do, here's how its useful, here's when not to use it" type of deal. If you're comfortable with the idea of trees, I'd start with this one. If not, perhaps a more gentler introduction may be in order, which is where the first source comes in. It's also good to note that the second link does not build a parser for you, giving credence to your competency in constructing or finding a tool for your needs URL: https://forum.audiogames.net/post/619038/#p619038 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. @6Don't try to fork the parser libs until you've used them in anger, and understand why they're what they are. They're as complicated as they are for a reason.@7If this is going to be needing order of operations and your resources don't discuss things like the shunting yard algorithm or similar to fix it, then using one of the parser libs is by far the best bet here. Getting order of operations right is remarkably tricky. This particular project is sitting just at the border of "writing a parser by hand isn't so bad" and "omfg it's still broken whhy". I'm not 100% which side it's on. URL: https://forum.audiogames.net/post/619048/#p619048 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. You may wish to check these out:This is a really good intro on parsing. I know people suggest using external libraries, but I'd implement one myself first to see how it all works. You'll learn much more doing so.The next two chapters also may give insights into how to structure your expressions. They build an AST (Abstract Syntax Tree), which is what the examples in post 3 are, just without the fancy class representations. Obviously you have a much simpler goal -- constructing a basic calculator -- but all you'd have to do is reduce the tokens you scan for.This serves as a good introduction, and perhaps a summary, of the first resource. Where the first source discusses it with you, guiding your thoughts along the way, the second is more didactic: "Here's what you do, here's how its useful, here's when not to use it" type of deal. If you're comfortable with the idea of trees, I'd start with this one. If not, perhaps a more gentler introduction may be in order, which is where the first source comes in. It's also good to note that the second link does not build a parser for you, giving credence to your competency in constructing or finding a toll for your needs URL: https://forum.audiogames.net/post/619038/#p619038 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. You may wish to check these out:This is a really good intro on parsing. I know people suggest using external libraries, but I'd implement one myself first to see how it all works. You'll learn much more doing so.The next two chapters also may give insights into how to structure your expressions. They build an AST (Abstract Syntax Tree), which is what the examples in post 3 are, just without the fancy class representations. Obviously you have a much simpler goal -- constructing a basic calculator -- but all you'd have to do is reduce the tokens you scan for. URL: https://forum.audiogames.net/post/619038/#p619038 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. @3In Python land, there's also Ply or Sly. Personally, they provide too much magic for my liking, and I'm considering making my own fork to address that. It might work slightly better for the OP, since you're basically talking about a mini _expression_ language anyway. URL: https://forum.audiogames.net/post/619028/#p619028 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. Yeah, for this you could use a regular _expression_, but it would be hideously complex and difficult to understand, no matter how you wrote it. You'd definitely be better off writing a full parser/lexer at this point. Parse the input into an abstract syntax tree (AST), then you can operate on it. For example: the input (2d6*8)*(3+3)**3 would be turned into the list [(, 2, d, 6, *, 8, ), *, (, 3, +, 3, ), **, 3]. That's what the lexer would give you. The parser, then, might turn this into something like [GroupingStart, Number(2), Character(d), Number(6), Multiply, Number*0), GroupEnd, Multiply, ...]. You could then perform algorithms to figure out what takes precedence and backtrack from there until you've simplified the _expression_. URL: https://forum.audiogames.net/post/618969/#p618969 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS.
You can also use eval to evaluate an _expression_, but please validate your input to see if it contains only numbers because if you're not careful it can run untrusted code.For example:>>> eval('2 * 3')6
URL: https://forum.audiogames.net/post/618928/#p618928
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS.
I would say this enough complexity that regex doesn't quite cut it any more. I mean you could probably still do it with regex, but it would be a mess and hard to understand.for this you need to actually parse the input into an data structure that represents the overall _expression_. let's say you would represent it using tuples. going to use python here, since I assume you are familiar with it.so any _expression_ would be of the general form:('op name', expr1, expr2, ... expr_n)where the first element just identifies the operation and the remaining elements are the children expressions the operation is applied to. so here is how they would look for basic math operations:('*', expr1, expr2) # multiplication('/', expr1, expr2) # division('+', expr1, expr2) # addition...('**', expr1, expr2) # exponentiationand so onso the _expression_3 * 5would be represented by ('*', 3, 5)however the operands can be expressions themselves, so1 + 2 * 3would be ('+', 1, ('*', 2, 3))and1 + 2 * 3 + 4would be represented by('*', ('+', 1, 2), ('+', 3, 4))the inner expressions are computed before the expressions that contain them. so the innermost expressions are computed first, and the outermost _expression_ is computed last.such a structure codifies the operations, operands, and the order to do them in. now you just need to figure out two things: how to parse th einput into such a structure and how to reduce it to the result.for parsing you can do this manually, but it is a bit tricky. instead you could use a parser combinator library like parsec or parsita for python. it allows you to put together your parser by plugging together parser priitives. like putting together legos. for complex grammars it would be even better to use a parser generator like yak or antlr, but this grammar is simple enough that it would be overkill.for reducing the structure to the result you can do it recursively or using a stack. recursion runs into the problem that if your structure is huge then you can run into stack overflow from the nested recursive function calls, but it is much simpler, clearer, and easier than using an explicit stack. so if you dont expect to need to process massive expressions, like in your case, then the recursive method is better by being much less complex.reducing such a structure to the result consists of recursively branching on the operator types. here is a reducer function for an algebra with just the + and minus operator for simplicity:def reduce_expr(expr): if type(expr) == int: return expr #already fully reduced op = expr[0] if op == '+': (operand1, operand2) = expr[1:] return reduce_expr(operand1) + reduce_expr(operand2) elif op == '-': (operand1, operand2) = expr[1:] return reduce_expr(operand1) + reduce_expr(operand2)#end defso with the above function, you give it an expr, which is either a number or a structure like I showed before. if the expr is a number, then it is fully reduced and there is no more work to be done.however if it isn't a fully reduced structure, it checks what operator to apply, it reduces the operands and applies the operator. keep in mind it keeps recursively calling reduce_expr, until it is fully reduced to just a number before applying the operator on the operands. to better understand this, it helps to put a print statement at the top of the function likeprint("reducing " + expr)to help you understand how it recursively traverses the structure as it reduces it.EDIT: the above function assumes it only deals with ints, i.e. whole numbers, so if one of your oprators can produce fractional results, you will run into a problem, since for a float the function wouldn't match on any of the if/else branches and return None. so if your algebra includes something like division, then in the base case (the if where you check if you are done) you need to check for both whether the expr is int or float.
URL: https://forum.audiogames.net/post/618909/#p618909
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS.
I would say this enough complexity that regex doesn't quite cut it any more. I mean you could probably still do it with regex, but it would be a mess and hard to understand.for this you need to actually parse the input into an data structure that represents the overall _expression_. let's say you would represent it using tuples. going to use python here, since I assume you are familiar with it.so any _expression_ would be of the general form:('op name', expr1, expr2, ... expr_n)where the first element just identifies the operation and the remaining elements are the children expressions the operation is applied to. so here is how they would look for basic math operations:('*', expr1, expr2) # multiplication('/', expr1, expr2) # division('+', expr1, expr2) # addition...('**', expr1, expr2) # exponentiationand so onso the _expression_3 * 5would be represented by ('*', 3, 5)however the operands can be expressions themselves, so1 + 2 * 3would be ('+', 1, ('*', 2, 3))and1 + 2 * 3 + 4would be represented by('*', ('+', 1, 2), ('+', 3, 4))the inner expressions are computed before the expressions that contain them. so the innermost expressions are computed first, and the outermost _expression_ is computed last.such a structure codifies the operations, operands, and the order to do them in. now you just need to figure out two things: how to parse th einput into such a structure and how to reduce it to the result.for parsing you can do this manually, but it is a bit tricky. instead you could use a parser combinator library like parsec or parsita for python. it allows you to put together your parser by plugging together parser priitives. like putting together legos. for complex grammars it would be even better to use a parser generator like yak or antlr, but this grammar is simple enough that it would be overkill.for reducing the structure to the result you can do it recursively or using a stack. recursion runs into the problem that if your structure is huge then you can run into stack overflow from the nested recursive function calls, but it is much simpler, clearer, and easier than using an explicit stack. so if you dont expect to need to process massive expressions, like in your case, then the recursive method is better by being much less complex.reducing such a structure to the result consists of recursively branching on the operator types. here is a reducer function for an algebra with just the + and minus operator for simplicity:def reduce_expr(expr): if type(expr) == int: return expr #already fully reduced op = expr[0] if op == '+': (operand1, operand2) = expr[1:] return reduce_expr(operand1) + reduce_expr(operand2) elif op == '-': (operand1, operand2) = expr[1:] return reduce_expr(operand1) + reduce_expr(operand2)#end defso with the above function, you give it an expr, which is either a number or a structure like I showed before. if the expr is a number, then it is fully reduced and there is no more work to be done.however if it isn't a fully reduced structure, it checks what operator to apply, it reduces the operands and applies the operator. keep in mind it keeps recursively calling reduce_expr, until it is fully reduced to just a number before applying the operator on the operands. to better understand this, it helps to put a print statement at the top of the function likeprint("reducing " + expr)to help you understand how it recursively traverses the structure as it reduces it.
URL: https://forum.audiogames.net/post/618909/#p618909
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Extended PEMDAS.
Re: Extended PEMDAS. I feel like the easiest way to do this would be to just do the dice calculations first, replace them with numbers and do the equation as normal in that case. I don't know the regex off the top of my head for this, but you could make a regex that singles out a number, then a D, then another number. Parse that, do the dice randomization, then substitute the number for the original string you singled out. URL: https://forum.audiogames.net/post/618847/#p618847 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Extended PEMDAS.
Extended PEMDAS. This has been a thought in the back of my mind for quite a while: I see Discord bots for dice rolling and such that have the advanced dicerolling, but also support the entirety of PEMDAS. I've sat down and tried to do it a few times, but I'm imagining this would take some RegEx and or Recursion skills that I definitely don't have. Let's take a few examples.First, let's say that I pass in:(1*8)*(3+3)**3Solve all of the parenthases first, so the equation ends up to be:8*6**3In this instance, ** is exponent, so the equation then becomes:8*216And then, we solve, to 1728. It would be really funny if I totally did this all wrong. It's actually been a minute sense I've had to use that stuff.Example 2: Original, but replace the original 1 with 2d6, which would mean 2 dice with six sides.(2d6*8)*(3+3)**3The difficulty here: I know how to do dice, just get a random number between amount of dice and amount * sides. The issue is how do we do all of this in a way that you can easily parse all of this. Let's just do the quick example, saying that 2d6 turned into 4.(2d6*8)*(3+3)**3 =32*216 =6912Any general logic will work if anyone wants to try their hand at this. My luck, it's super simple and I'm just dumb. URL: https://forum.audiogames.net/post/618842/#p618842 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
