Properties
Category
English
Similar Topics
Statistics
Comments
83
Participants
7
Subscribers
8
Votes
1
Views
716
Share
Inequalities in LPP
Answered
I am trying to make a ggb applet for LPP (Graphical method). In that I need free hand movement of lines or inequalities. Is there a way to give free hand moment to lines (or any object) in graphical view? Please give me some geogebra applets (esp. LPP) anyone has done in which free hand movement of inequalities could be made possible.
 GeoGebra
 Help
 Partners

Contact us
 Feedback & Questions
 This email address is being protected from spambots. You need JavaScript enabled to view it.
 +43 677 6137 2693
© 2021 International GeoGebra Institute
I am going to assume that LPP means "Linear Programming Problem" in this context. You might find something here.
Or provide more details what exactly you want to be able to do.
explain „free hand movement“
see https://www.geogebra.org/m/weyhrbrq
for graphical LP
If you define the borders of the inequalities as lines between two points (let's say a line f through A and B), you can drag them. Show the equation in the form y = ax + b and define the inequality as y < RightSide(f) to get an inequality you can drag. I assume that's what you're looking for. If the possibility to drag objects is just needed to find the optimal solution, just use the method of defining a line between two points to create that one line, leaving the inequalities theselves fixed.
chris
chris
Thanks a lot artdent, hawe for the links you have given. Special thanks to Sir Chris for providing me my exact need at this moment. I saved it with the name Chris’s half plane. 😍😘
una sugerencia
Todos los comandos tienen su ayuda en inglés y el uso que les doy es simple siguiendo estas ayudas. Inténtalo y si no puedo explicar en español
the syntax of if is if(<condition>,<then>,<else>) or if(<condition>,<function>,<condition>,<function>........)
your condition is not. see the commas:
if(cb1&&cbX&&cbY&&!(cb2cb3cb4cb5cb6),c1&&cX&&cY,
cb1&&cb2&&cbX&&cbY&&!(cb3cb4cb5cb6),c1&&c2&&cX&&cY,
cb1&&cb2&&cb3&&cbX&&cbY&&!(cb4cb5cb6),c1&&c2&&c3&&cX&&cY,
cb1&&cb2&&cb3&&cb4&&cbX&&cbY&&!(cb5cb6),c1&&c2&&c3&&c4&&cX&&cY,
cb1&&cb2&&cb3&&cb4&&cb5&&cbX&&cbY&&!(cb6),c1&&c2&&c3&&c4&&c5&&cX&&cY,
cb1&&cb2&&cb3&&cb4&&cb5&&cb6&&cbX&&cbY,c1&&c2&&c3&&c4&&c5&&c6&&cX&&cY)
so I see if(<condition>,<condition>,<condition>,<condition>,<condition>,<condition>,<condition>,<condition>)
you must clarify your goal and condition
No es fácil de hacer lo que quieres por varias razones. La primera es que GG no está preparado para utilizar listas de inecuaciones; por ejemplo no existe la funcion .AND. para listas semejante a sum() ni un product() que me permita simularla.
he hecho unas pruebas y escribiendo algo he podido casi hacer que funcione como tú esperas. por ejemplo he tenido que crear algo similar a true pues ni siquiera true es una funcion así que no se puede escribir algo como x+y<3&&true o x+y<3false. después de varias pruebas he conseguido que casi todo vaya bien
no sé qué ocurrirá cuando se desmarquen todos las casillas pero eso es problema de diseño que se suele resolver haciendo que eso no ocurra
también se me ha ocurrido que una herramienta personal podría crear la condicion a partir de un listado de inecuaciones seleccionadas para todos los casos de una cantidad inferior a 10 o 20 inecuaciones
Other construction site
What about special to inequality variables cX, cY  do not accept x AND y as variables
 direct input to value property ==> invalid function : please enter an explicit function in y
 have a 'Show trace' property (others have not)
 missing Style  Filling property (cX)
I guess this variables have been line functions in former live changed to an inequality?
must be exchanged for a new variable to include a complete inequality in x,y
perhaps a bug?
si quieres que un input box admita una o dos variables al principio debe ser creado con 2 variables
en el adjunto en un input box se admite x+y>=0 y en el otro no la diferencia es cómo fue creado el objeto enlazado antes de crear el input box
es más: he probado t>=0 y luego he creado el input box correspondiente. el input box admite inecuaciones con t pero no admite ni x ni y
Thank you all scholars for your ideas. I have to go for duty after 4 hours. Now I have to rest. Evening I will work on this and will respond.
I can see the optimal feasible points FP (same as l1 in mathmagic's) following mathmagic's program. But neither I could see the feasible solutions FS (=l2 in mathmagic's) nor could I see the maxFP and minFP. Finally, the line Z=k, which determines the optimal solution, vanishes all along when the input command Z=k is given.
I just realized that there is another problem with my javascript code. I worked with the basic string representation of the inequality variables because that seemed simple way, but those string representations already have rounding incorporated, which means that the newformed inequalities might be far less accurate than the original ones (a 0.004 might become a 0 if the rounding is set to 2 decimal places for example). When I have time later I try to change that. Maybe there there is a different representation I can access, or better I work with the content of the input boxes (hope I can access those easily via script).
@hawe @artydent @mathmagic
After following hawe's and mathmagic's algorithm, when I checked the last constraint in hawe's, the half plane y>=3 is not appearing in the graph.
This is fine running in downloaded GeoGebra platform. But everything everything disorganized in online ggb platform, i.e., the feasible points and the optimal feasible points when I changed all the input boxes and when some of them left undone. Also, the feasible region (the Area) is not displayed in the graphics view:
When I uncheck all the input boxes including that of Objective Function the primary error occurred. Anyone please check and help me also in this.
hm,
it’s OK for me local and online app
https://help.geogebra.org/c..." alt="/c493098086904fc6971119ff21d1fab5" />
can not load your file (ipad)
please upload your file as activity
to much local foro*, LPP* files
So I was playing around a bit more with my latest version to possibly make a workaround for "wrong drawing window" problem when using a constant objective function and discovered two weird things: 1) a display issue I can't explain, and 2) an possible solution to the problem, but it manifested by accident and I don't know how to reproduce it.
Under some circumstances (e.g. when the the feasible region is an "open polgon") this happens: make the objective constant and then change it back to something nonconstant, the feasible region is suddenly not drawn anymore. It's not that the computation of the feasible region fails (it's actually not even recomputed at all, because it doesn't depend on the objective function), it just is not displayed anymore.
Moreover, when this happens and constraints are changed afterwards, the new feasible region is computed properly, but it is still not drawn. Only upon checking or unchecking a constraint checkbox, the feasible region is drawn again.
The original "LPP with special case handling.ggb" (attached) behaved like this: For a "proper" objective function, the object constline has the type Line (shown in Algebra window if sorted by object type). Whenever the objective function is changed to a constanf function, the type of constline would automatically switch to Implicit Curve with value "0=0" or "0=1" or "0=1". (This type switch the reason why the object resets its drawing location, and is supposedly a deliberate feature of GeoGebra.) And when the objective function is changed back to something nonconstant, the type of constline switches back to Line.
After some playing around I somehow ended up with "LPP with special case handling2.ggb" (also attached) which has a different behaviour. Here the type of constline always remains Line, even when the objective function becomes constant (in which case the value of constline just becomes Undefinded).
I have no idea how that happened, or how to reproduce that, or if it's even sure that it won't randomly revert back to the other behaviour. If this reproducible, i.e. if I can tell GeoGebra somehow to definitely not change the type of the object, then this would solve the "wrong drawing window" problem, because without a type change, the drawing window doesn't reset.
Does anybody have some explanations?
Pienso que todos estos problemas se pueden ir resolviendo con la redefinición de los objetos mediantes falsos objetos (dummy) . Por ejemplo definir la recta como
if(Z(1,0)==Z(0,1)&&Z(1,0)==Z(0,0), y=y(corner(3))+1, Z(1,0) x +Z(0,1) y+Z(0,0)=k)
entonces la línea existe pero nunca es visible
So, here is new, polished version without the need for any scripts. Now, the only "problems" should (hopefully) be "bad" user input (e.g. nonlinear stuff) but that is hard to avoid anyway.
That said, the whole "using Input Boxes with Symbolic flag to enforce certain types" approach didn't work in the end, even though it looked great at first. Not sure why. Maybe that only really works, when the linked variable is only set by Input Box itself? Or I did it wrong somehow? Anyway, what happened was this: I had made sure all inequalities used both variables and that constline was actually of type Line, then I made dummy Input Boxes for each equality and for constline and checked the Symbolic box. (I didn't replace the original inequaliy input boxes because of layout issues; the Symbolic ones are higher and even change height according to input, e.g. fractions make them even bigger.) It seemed to be working at first, constline kept its type even when using a constant or nonlinear objective function (value just became Undefined as expected), and the feasible reagion was calculated properly via Iteration command even when using inequalities with just one variable. Unfortunately it didn't last. I kept polishing up other stuff and playing around a bit, when I suddenly noticed that constline was of type Implicit Function (with value 0=1 or so, because the obj. function was constant at that time) instead of Line. Aaaaaarrrrrggggghhhhhh!!!!! And even worse, when I changed the obj. function back to something linear, constline stayed an Implicit Function and had an Undefined value. (So maybe the Input Box worked after all, just not all the time.) So I then also played around a bit with the inequalities, and  unsurprisingly at that point  there soon was same problem as we had before, the Iteration command would swap the x and y coefficients, producing a completely wrong feasible region. Oh well, so much for typeenforcing via input boxes.
Anyway, I already had a different workaround for the inequality issue and implemented that one instead: For the inital list CB already, the inequalities aren't used as they are but each inequality in conjunction with "x+y<infinity". It makes it look somewhat ugly in the end, but that way all inequalities in the various lists have the same type and all the list operations work properly.
Comments have been locked on this page!