Inequalities in LPP

bennyjacob shared this question 5 months ago
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.

Comments (83)

photo
1

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.


photo
1

explain „free hand movement“

see https://www.geogebra.org/m/weyhrbrq

for graphical LP

photo
1

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

photo
1

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. 😍😘

photo
1

una sugerencia

Files: foro.ggb
photo
1

Mathmagic,

Thanks a lot. It will take time to understand your commands. Can you explain the commands used.

photo
photo
1

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

photo
1

Got it.

Saludos.

photo
1

Dear Mathmagic,

Will you tell me why I cannot define Z(FP) (which is equivalent to b(l1) in your applet)?

Files: LPP4.ggb
photo
1

I can not open your file


some very long conditions have a problem

photo
1

Dear mathmagic,

The ggb error occurred as I have saved the file after checked the checkboxes. The checkboxes are for the constraints although not assigned to the constraints. Please open the attached file. This will be working without error. I have verified and uploaded.

Now, please tell me why I cannot define Z(FP) (which is equivalent to b(l1) in your applet)?

Can you give some suggestion to make a condition without error even after checking the checkboxes. Otherwise, you please help me in use this applet for any set of constraints and objective function with your algorithm? The condition I used here is:

if(cb1&&cbX&&cbY&&!(cb2||cb3||cb4||cb5||cb6),c1&&cX&&cY,

cb1&&cb2&&cbX&&cbY&&!(cb3||cb4||cb5||cb6),c1&&c2&&cX&&cY,

cb1&&cb2&&cb3&&cbX&&cbY&&!(cb4||cb5||cb6),c1&&c2&&c3&&cX&&cY,

cb1&&cb2&&cb3&&cb4&&cbX&&cbY&&!(cb5||cb6),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)


Thanking you in advance.

Files: LPP0.ggb
photo
1

you can make a numeric evaluation

true = 1, false=0


a && b ... a*b == 1

a || b ... a+b > 0

photo
1

Sir,

This is not clear to me. Will you make suitable changes in your ggb file or my file and upload.

Thanks and regards

Benny Jacob

photo
1

Why to put a||b>0? Please give the reason?

photo
1

Dear mathmagic,

This is not working. Will you please explain?

photo
photo
1

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&&!(cb2||cb3||cb4||cb5||cb6),c1&&cX&&cY,

cb1&&cb2&&cbX&&cbY&&!(cb3||cb4||cb5||cb6),c1&&c2&&cX&&cY,

cb1&&cb2&&cb3&&cbX&&cbY&&!(cb4||cb5||cb6),c1&&c2&&c3&&cX&&cY,

cb1&&cb2&&cb3&&cb4&&cbX&&cbY&&!(cb5||cb6),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

photo
1

The bold part is the condition and after coma is the function based on the condition. This is working when I check the exact checkboxes. But the problem is I cannot leave a few of the input boxes vacant, doing so this error occurs.

photo
1

I am not very happy with the approach - what about "free hand moment",

but try

CB={c1, c2, c3, c4, c5, c6}

Mask={cb1, cb2, cb3, cb4, cb5, cb6}

Constrains=RemoveUndefined(Sequence(If(Mask(j), Element(CB, j)), j, 1, Length(CB)))

with Update script Execute({ReplaceAll("Area="+Text(Constrains), "," ,"&&")})

photo
photo
1

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<3||false. 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

Files: foro.ggb
photo
1

@mathmagic

Working with lists of inequalities is not impossible, just somewhat annoying to do. I recently had the same problem, trying to join all inequalities in a list (of arbitrary length) by AND. This is how I managed:

L_{ineq} = {x + 2y ≤ 10, 2x - y ≥ 1, x ≤ 6, x ≤ 11y}
Element(Iteration(Flatten({Element(L, 1) ∧ Element(L, 2), If(Length(L) < 3, {}, Take(L, 3))}), L, {L_{ineq}}, Length(L_{ineq}) - 1), 1)

This can handle lists of arbitrary length >1. (Length 1 is of course simple and can be added with an extra check at the beginning.)

photo
1

thanks for the idea

photo
1

@artydent

What does L represent?

The GeoGebra software is new to me. So, can you give your applet to understand how you managed to join the list of inequalities of arbitrary length by AND? Kindly upload your work, so that I can understand and improve my skills in making algorithms.

photo
1

Dear mathmagic,

Will you explain how the logical inequalities 'tr' or 'a' in your algorithm managed to solve the error occurred in my condition on constraints using if command?

photo
1

@artydent

This is how your algorithm works in my applet:

photo
1

The "L" ist just the <Variable Name> in "Iteration( <Expression>, <Variable Name>, <Start Values>, <Number of Iterations> )", it refers to the the value in each interation.

The <Start Values> is a list with the starting values for L. In this case it's only one starting value which is L_{ineq} (the list of inequalities).

<Expression> describes how L changes in each iteration. In this case it joines the first two elements by AND, and keeps the rest as is. (You can think of it as replacing the first "," in the list by "∧".) So the length of L is decreased by 1 in each iteration. The first element of L always contains a conjunction of inequalities, and in each iteration one inequality joins this conjunction. The <Number of Iterations> is Length(L_{ineq}) - 1; after that many iterations L has only one element which is the conjunction of all initial inequalities.


See also https://wiki.geogebra.org/e... for how this command is used.


That said, I just noticed a curious thing: In the result, inequalities sometimes have "x" and "y" swapped, effectively making them completely different inequalities. Maybe that's just a bug. Or maybe lists with inequalities aren't really supported, in which case we simply can't expect to get reliable results from this approach (which would be a shame). In any case, at the moment this approach doesn't work!


In case this is just a bug and can be fixed or worked around:

In your applet, you are currently using it with all the inequalities instead of just the ones that have their boolean flag set to true. This can be changed easily like this:

L_{flags} = {cb1, cb2, cb3, cb4, cb5, cb6, cbX, cbY}
L_{ineq0} = {c1, c2, c3, c4, c5, c6, cX, cY}
L_[ineq} = RemoveUndefined(Zip(If(flag, ineq, ?), flag, L_{flags}, ineq, L_{ineq0}))

photo
1

Oops, accidentally submitted before finishing. .... Will be updated.

photo
1

Damn, submitting the edit of the last post didn't go through, and I hadn't saved the text. So here comes the rewrite, or at least a shorter version of it.


Apparently, inequalities with just one variable are of a different type than inequalities with both x and y. And list elements all need to have the same type, otherwise list operations have unexpected behaviour, and that is why that weird problem with swapping x and y occurred.

So not all ist lost, it's just necessary to modify inequalities like "y≥0" to something like "0x+y≥0", then we can work nicely with lists of inequalities.

I don't think it's reasonable to expect the users to take care of this, so this should be done automatically. I didn't find a way to do it regular commands or GeoGebra scripts, but it's possible with Javascript. The basic idea is to add a new variable for each inequality that holds a list-friendly version of that inequality, which are then used (instead of the original inequalities) to construct the inequality list. To make this work, this transformation needs to happen whenever an inequality is updated, and also upon starting the applet.

Attaches is a solution. It contains function in Global Javascript that makes such a modfification (with variable names as parameters). This function is then called in the ggbOnInit() for all the inequality variables and also in On Update for each of the variables.

photo
1

@artydent

The setting of commands in your file LPP-javascript cannot be opened in geogebra. How I can open the settings? Where I can learn JavaScript for geogebra?

photo
1

What do you mean by "opening settings"? In the properties panel of an object there is a tab "Scripting", and in there is a tab "Global JavaScript" and potentially other tabs like "On Click" or "On Update", depending on the type of object. There you can find and edit all the JavaScript Code.

As for learning "JavaScript for GeoGebra", it's regular JavaScript and GeoGebra provides an API. You can find infos zur API here. It probably helps if you have a little experience with JavaScript from other places, but the intricate details of JavaScript are most likely not that important for the kind of scripts you want to use with GeoGebra. If you have a little experience in any kind of scripting or programming language, it might be enough to just look at a few example scripts, look stuff up in the API-reference and try around a little.

That said, for this particular problem with the inequalities, hawe now has a nice solution that is just a one-liner in GeoGebra script. No need to use Javascript (where most of the lines were just handing the translation between GeoGebra objects and JavaScript objects anyway).

photo
1

Thank you

photo
photo
1

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?


/++LPjukbLwwCPMfDFcQxanZDsZ9PT7IJ9q+v+aOf4wGfTTjgAAAABJRU5ErkJggg==

must be exchanged for a new variable to include a complete inequality in x,y

perhaps a bug?

photo
1

Hm...that with the undefined value doesn't happen for me, except when trying to use "SetValue" which doesn't work because the variable has a different type. Other than that I can change the variables however I want. (I use GeoGebra Classic 5.)

The "Show trace" behaviour is also somewhat peculiar for me, it depends on how I change the variable. If I use the Algebra window or the general Input field set a variable to an inequality with just one variable then it gets the property "Show trace", and if I set it to a variable with both variables then it doesn't get this property. BUT if I use the Input Box that the variable is connected to and change from a 1-variable-inequality to a 2-variable-inequality (or the other way around) then the "Show trace" property doesn't change but stays as it was before.

photo
1

Das mit SetValue versteht ich jetzt nicht - die Inputbox schreibt ja nach cX bzw. cY

Ich hab mit der Datei LPP0.ggb von benny weiter gearbeitet.

Status Quo: https://www.geogebra.org/m/xe6hvncn

Ich tausche die Variablen bei Gelegenheit aus um flexibler zu sein...

Bei Deiner js-Datei tritt das Problem aber auch zu Tage....

photo
1

@hawe Ja, hatte das Problem gestern nicht, weil ich vermutlich bei dem vorherigen Testen die Input-Boxen schon "versehentlich" auf den 2-Variablen-Typ gesetzt hatte. Ist gefixt in meiner neuen Version (siehe Antwort weiter unten, mathmagic hatte das genaue Problem erkannt).

photo
photo
1

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

Files: foro.ggb
photo
1

That seems correct, I can reproduce that.

Interestingly, yesterday my cY-box would also accept inequalities with x and y, but I guess I had changed cY manually to such an inequality during my testing so that's why the Input Box already had this type.


Fortunately, an Input Box that accepts inequalities with x and y will also accept inequalities with only one the two variables, just not the other way around. So it's only necessary to force every Input Box to the 2-variable variant.


Attached is a version that does exactly that with an init script. The script simply redefines every inequality variable to an inequality using both x and y (to force the Input Box to accept those types), and then sets the variable back to its original value (via SetValue) which doesn't change the type of the Input Box.

photo
1

Actually, now that the Input Boxes are forced to the two-variable type, I guess the variables also retain this type even when only one variable is used. So I guess the list operations would work properly now even without adding "0x" and such. Not sure though. Would depend on how the list creation works internally, i.e., if the elements retain that 2-variable-property or if that stuff is re-interpreted.


Edit: Nevermind, the "0x" stuff is still needed. I just managed to produce wrong results again without it.

photo
1

Hm,

bist Du sicher, dass Du das js-Gedöns noch brauchst nach dem alle ci varaiblen doch jetzt von gleichen typ sind?

Ich hab mir erlaubt alles auf die ci variablen zurückzubauen und js niederzumachen - läft... :wink: glaub ich?


Edit: Wo wäre das Problem dann in der geänderten Datei festzumachen.

photo
1

Take for example the file you just posted, change the content of the Input Box CY to "y≥3" and set the corresponding CheckBox. The list operations that compute the area won't work properly, that inequality is changed to "x≥3" in the process. You can easily se that the wrong area is drawn. So that part of the script is really necessary if the goal is to use the list approach. (Not quite sure if the behaviour is consistent, maybe you have to try a few other things to make it produce such a problem.)


As for the init script to make the boxes the proper type, I guess that one is not strictly necessary anymore once you force the Input Box to have the correct type. (I had assumed that - upon closing and re-opeining the file - those boxes would be recreated from the inequalities again, but apparently not.) It's still kind of a failsave though. (If you happen to redefine one of the inequalities in the Algebra view with just one variable, it changes the type of the Input Box, which you might not notice. With the script, this is automatically rectified whenever the file is opened.)

photo
1

Hm,

kann ich nicht bestätigen - läuft ohne script tatellos.

Ich allerhand rumgemacht an den Nebenbedingungen...

/AXzOQVFL4LLSAAAAAElFTkSuQmCC

photo
1

Schau auf Dein Bild, diese Fläche ist durch "x≥3" beschränkt, nicht durch "y≥3" wie es sein sollte. Der Fehler passiert in dem Kommando, wo die Liste der Ungleichungen mit UND verknüpft wird.

photo
1

Ahh, ja, da liegt der Hase im Pfeffer.

Man muss aber nur das y nachschieben, das x handelt er richtig ab?

Als Alternative ein Updatescript für die InputBox

If(¬IsDefined(IndexOf("x", Text(cY))),Execute({"SetValue(cY,0x +"+Text(cY)+")"}))

Da käme man ohne zusätzlichen Varaiblensatz aus...

Dann gefällt mir meine Lösung besser, weil es nur an einer Stelle Script braucht ;-).

photo
1

Ah super. Nach sowas in der Art hatte ich urpsrünglich gesucht. Bin nur auf Javascript umgestiegen, weil ich nichts gefunden hatte. Das wäre also ein schönes knappes GeoGebra-Script.

Aber was meinst Du mit "an nur einer Stelle"? Das muss ja trotzdem für jede Variable gesetzt werden. Und ist in gewisser Weise sogar ekliger, weil man da kein Global hat, um eine allgemeine Funktion zu definieren, man muss also in der Codezeile aufpassen, dass man überall die Namen an allen Stellen richtig ersetzt. (Oder evtl. gibt es ein Kommando für "die Variable, zu der dieses Script gehört"?)

Einen zweiten Variablensatz würde ich aber trotzdem nehmen, weil das Ändern der ursprünglichen Variable ja automatisch auch den Inhalt der Input-Box ändert, was für den Nutzer eher unschön und potentiell verwirrend ist.

Auch das Genauigkeitsproblem (das ja auch mein JavaScript noch hat) lässt sich gut beheben. Durch "Text(cY)" kriegt man nur den Anzeigetext, der schon durch Rundungen und wer-weiß-was verfälscht ist. Hab keine Ahnung, wie man aus "cY" was besseres extrahiert, aber "text(InputBoxY)" (oder wie immer die gerade heißt) scheint zuverlässig den wirklichen Eingabetext der Inputbox zu liefern, das wäre besser geeignet. Dann könnte man im Prinzip sogar die originalen Ungleichungsvariablen weg lassen, die mit den Inputboxen verbunden sind. Stattdessen die Inputboxen mit keiner Variable verbunden und per Script der Inputbox die Variablen der "erweiterten" Ungleichungen aktualisieren.


PS: Ganz schön fies das mit "der Hase im Pfeffer"....für Leute, die das mit google übersetzen lassen. ;-)

photo
1

Ach ja, ich muß daran denken, daß auch andere Mitlesen....

deepl macht daraus "that's the fly in the ointment." auch nicht schlecht ;-)


Ich hab meine Lösung weiter oben vorgestellt, als da wäre

CB={c1, c2, c3, c4, c5, c6}
Mask={cb1, cb2, cb3, cb4, cb5, cb6}
Constrains=RemoveUndefined(Sequence(If(Mask(j), Element(CB, j)), j, 1, Length(CB)))
with Update script 
Execute({ReplaceAll("Area="+Text(Constrains), "," ,"&&")})
ergänzt mit
Execute({"eq(x,y)="+Element(Area, 1)})

und auch hochgeladen https://www.geogebra.org/m/xe6hvncn

Is aber eine Superidee mit Iteration zu arbeiten, die kann ich sicher noch öfter verwenden, Dank dafür...

Ich hab hier https://www.geogebra.org/m/weyhrbrq

schon was ähnliches. schreibe aber die NB gleich in eine Liste, dann gibt es keine Schranke nach oben - vielleicht arbeite ich die Erkenntisse dieser Diskussion ein?

Falls Du ein LP mit dem Simplex rechnen willst, siehe

https://www.geogebra.org/m/fP8cnZbb

vielleicht zur Überprüfung des graphischen Ergebnisses ;-)

photo
1

Stimmt, es ist natürlich sinnvoller, die ganze AND-Operation einfach mit einem Skript zu machen, wenn man eh nicht um Skripte drumherum kommt.

Ist schon schade, dass das via Iteration nur funktioniert, wenn man den Typ der Ungleichungen anpasst und das wohl nicht ohne Skript geht. Hatte mich da etwas reingesteigert.


Mal noch ein paar Anmerkungen zu Deiner Lösung:

  • Durch das Arbeiten mit "Text(Constrains)" geht potentiell wieder was schief, wenn der Nutzer da Kommazahlen eingibt, die im Text nur gerundet auftauchen. Nicht wirklich problematisch, um es als Lehrmaterial zu verwenden, dannvermeidet man sowas halt.
  • Apropos, die Liste sollte vlt. auch besser "Constraints" heißen. ;-)

  • Dadurch, dass nur die Eckpunkte des zulässigen Bereichs überprüft werden, wird das Ergebnis falsch, wenn die Zielfunktion unbeschränkt ist auf einem (natürlich auch unbeschränkten) zulässigen Bereich. Könnte man noch abfangen.
  • Wozu die beiden Zeilen im CAS? Als Anzeige gedacht bei ausgeblendetem Algebra-Fenster?

photo
1

Wie mir gerade auffiel, kriegt man die Ungenauigkeit durch das Verwenden von "Text(...)" auch recht leicht weg. Da man bei "Execute" ja Strings angibt, kann man ja auch mit den Strings für die Listenelemente anstatt anstatt den Ergebnissen von "Text()". Also Im Skript z.B.

Execute({"Area:"+Sum(Sequence(If(k > 1, "&&", "") + "Element(Constrains," + (k) + ")", k, 1, Length(Constrains)))})

Bzw. noch mit extra Mengenklammern, falls "Area" wieder eine einelementige Liste werden soll.

photo
1

@artydent @hawe

Both of you kindly upload your final ggb file.

photo
photo
1

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.

photo
1

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.

photo
1

Your definition of maxFP and minFP is wrong. It should be

maxFP = KeepIf(Max(FS) ≟ Z(P), P, FP)

i.e. replacing "Max(FP)" by "Max(FS)" insider (or better even use "MaxFS" to avoid having the max computed for each comparison).


As for your line, I don't know exactly what the problem is, but if you just wrote "Z=k" in the input line, then this probably just redefined the function Z. Write something like "blabla:Z=k" (which creates an object named "blabla" that is the line you want).

photo
1

Z=0 redefine Z

0=Z creates an implicit plot or line

photo
photo
1

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 new-formed 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).

photo
1

@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.

photo
1

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.

photo
1

hm,

it’s OK for me local and online app

https://help.geogebra.org/c..." alt="/c4930980-8690-4fc6-9711-19ff21d1fab5" />

can not load your file (ipad)

please upload your file as activity

to much local foro*, LPP* files

photo
1

Here the FeasibleRegion (Area in artydent's and your file) cannot be displayed. This, I suppose, may happened due to the repetition of inequality 5x + y <= 100. Also, I cannot open the second file after all inequalities are removed from the input box (see the second picture attached). I used your commands:


CB={c1, c2, c3, c4, c5, c6}

Mask={cb1, cb2, cb3, cb4, cb5, cb6}

Constrains=RemoveUndefined(Sequence(If(Mask(j), Element(CB, j)), j, 1, Length(CB)))

and then artydent's command:

Execute({"Area:"+Sum(Sequence(If(k > 1, "&&", "") + "Element(Constrains," + (k) + ")", k, 1, Length(Constrains)))})

followed by mathmagic's algorithm to complete the applet.

photo
1

Also,

programming is up to 90% debugging. If you mixing up different approaches then you have an extra session of debugging - it is a little bit optimistic to outsource the resulting problems?

As I can see

- Constrains (we should rename it to Constraints to feed artydent;-) is not be indented to graph, this is Area in my concept, possible FeasibleRegion in yours (is not graphed) and responsible for Error-Report. Do debugging to define graphing area of inequalities as it is suggested...

photo
1

Will you help me to complete my problem without debugging?

Seeks everyone's solution in their completed form to my problem.

photo
1

Removing inequalities from InputBoxes (or unchecking too many checkboxes) is generally problematic at this point. A lot of the stuff used completely breaks with such corner cases (with an actual error message, not just some undefined objects). There needs to be extra handling for things like "too few (even zero) selected inequalities", "unbounded regions" (expecially ones without "corners" because then the Vertex command fails) etc.

That has been bugging me all along but it didn't have priority. I had started to implement a few measures to handle such things, but it's not that easy and I don't really have time the next few days. I might look at it more closely this week. (Want to practice with GeoGebra anyway.)

Looking at your file I don't see any OnUpdate script for Constrains (that's where that "Execute" command needs to be). It looks like you just executed that command once from the input line. That gave FeasibleRegion a definition that worked for the inequalities at that time, but is not updated when you change inequalities. Now that you have too few inequalities in Constrains, FeasibleRegion is Undefined.

As for your first screenshot, I don't quite understand why FeasibleRegion can't be displayed there, the multiple occurence of the one inequality shouldn't have that effect.

photo
1

@artydent

Eagerly waiting for your solution with lot of thanks in advance.

photo
1

Here again, the maximum feasible solution is not correctly showing in the graph in the first attempt when new set of constraints are given. The exact graph with optimal feasible solutions are displayed only after once saved and reopen the ggb file, but without the FeasibleRegion (Area in yours):

photo
1

Thanks to artydent for debugging - back to my desktop I can load your file now.

Removed incompatible stuff and added my script to, now, Constraints variable. Is a list and eq(x,y) is the area function for evaluating the FeasibleRegion

photo
1

Dear hawe,

Will you please explain in detail how you resolved the debugging issues? Please give also in details the commands you have used here.

photo
1

@hawe

Will you please check the work I have just filled in using your stuff. Kindly give me the commands you have used in CB, Constrains, FeasibleRegion and in eq.

photo
1

I think you want zunBdd for z(x,y)<=max and z(x,y)>=min

photo
1

Sir,

This is the rule:

In case, the feasible region is unbounded, we have:

(a) M is the maximum value of Z, if the open half plane determined by ax + by > M has no point in common with the feasible region. Otherwise, Z has no maximum value.

(b) Similarly,m is the minimum value of Z,if the open half plane determined by ax + by < m has no point in common with the feasible region. Otherwise, Z has no minimum value.

photo
1

Definiciones circulares según me parece

photo
1

I have done a rework to overcome limited constraints

and run in to problems with 5.x may be someone can have a look to

https://help.geogebra.org/t...

is it reproducible? a Version 5.166 shows the same behavior.

photo
1

@mathmagic

Working fine, right!

photo
1

I made a version that should handle invalid constraints, empty feasible region, unbounded feasible region, unbounded objective functions, unbounded optimal regions.

Doesn't use any scripts aside from the Update script on Constraints we already had.

Uses a lot of auxiliary variables, partially to make things easier to code, partially to avoid circumvent Geogebra errors.


Known issues:

  • Inequalities that would (for any x, y) evaluate to true or false (like "1≥0" or "x+y-x>=y" or "0x+0y+1≥0") don't work properly.
  • When entering a constant objective function (even though the calculations all work properly), the drawing location of the line "k = Z(x,y)" switches to Graphics 2, and it will stay there even after switching back to a "proper" objective function. (Apparently, that's not considered a bug, GeoGebra just resets the drawing location to the currently active Graphics window when this kind of dependent object is "redefined" after geting a different type than it had before. Only way I see to circumvent that behaviour would be to move the Input Box of Z to the first Graphics window.)

If you find more issues, let me know.

photo
1

clic in cb5

photo
1

Clicking cb5 results in an empty feasible region. Seems to work fine for me. What's the problem for you?

photo
1

Sorry it is ok (with last version 634)

photo
photo
1

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.

  1. weird display issue:

    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 non-constant, the feasible region is suddenly not drawn anymore. It's not that the computation of the feasible region fails (it's actually not even re-computed 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.

  2. accidental "wrong drawing window" fix:

    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 non-constant, 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?

photo
1

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

photo
1

That one has the problem of being undefined for valid objective functions like Z(x,y)=x+y-1. No problem though, I already have a different dummy solution to make sure that the object is always a of type Line.

Nice idea using "corner" to always hide the line. I was now using an update script to hide the line, but the corner solution is nicer in terms of maintaining the code. Combining this with my dummy solution:

dummyPointsConstline = Unique(RemoveUndefined(Join({Sequence((t, Element(Solutions(Z(t, y) = k), 1)), t, 0, 1), Sequence((Element(Solutions(Z(x, t) = k), 1), t), t, 0, 1), {(0, y(Corner(3)) + 1), (1, y(Corner(3)) + 1)}})))
Line(dummyPointsConstline(1), dummyPointsConstline(2))


And even though the visibility problem is solve, I still would like to understand why the two versions before had different behaviour regaring the type change.


And the whole "feasible reagion is not drawn" problem also remains, it had nothing to do with the line problems.

photo
1

I found how to solve the problem with the "feasible reagion is not drawn". I just don't store the "optimal region" anymore when it is a inequality (i.e. if the objective function is constant and the feasible region is two-dimensional). Attached is the whole thing now


I am not 100% sure why the problem occured, but my guess is the following:

In case of a two-dimensional feasible reagion and a constant objective function, there were three objects (all supposed to be drawn) containing that region (two of them just referenced the first object). Even in that case Geogebra would only draw the one object and ignore the other two for some reason. And when switching back to a non-constant objective function, only one object contained this region, and I think GeoGebra somehow "got confused" there and didn't draw it at all anymore (at least for some unbounded regions). Maybe that's just one of those internal GeoGebra things that are supposed to happen exactly this way, but maybe it's a bug. I'll try to get a small problem example and make a report.

photo
1

In Verfolgung Deines Bug-Reports:

Könnte es sein, daß Deine Interation bedient von einer InputBox mit gesetztem Symbolic-Flag funktioniert?

nach dem was Michael gesagt hat wäre es einen Versuch wert?

Ich hab ja noch die Datei mit ausgebautem js - da tut es wie mir scheint....

photo
1

Ja, das funktioniert, hab ich schon getestet. Bin gerade dabei, das Ganze ein wenig zu überarbeiten.

photo
photo
1

So, here is new, polished version without the need for any scripts. Now, the only "problems" should (hopefully) be "bad" user input (e.g. non-linear 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 type-enforcing 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.

photo
1

constline was of type Implicit Function
If you can provide a set of steps to reproduce that we can take a look

photo
1

I'll give it a try to find some reproducible steps.

photo
1

So I I think I found out what the issue is: Saving and loading when the type-safe object definition doesn't have the enforced type on its own.

Just open the attached "Typefail - Basic", change the content of the visible InputBox to something nonlinear or constant, and the value of 'constline' properly becomes 'Undefined' (because it is type-safe via a hidden Symbolic InputBox). Now save and load the saved file again. Now 'constline' is of some other type (depending on what you had typed in the InputBox) and that new type is now protected. (The saving part was still fine (the xml listed 'constline' as of type 'Line', but upon loading the object type is set based on the content of the InputBox.)

So the good news is that it doesn't seem to be a general bug in the whole "protecting object type via symbolic InputBox". The file loading just doesn't specifically deal with a situation where the linked object is a dependent object: The InputBox depends on the linked object so it must come after it in the construction order, but that means that during the loading process the linked object can freely change its type before the InputBox is loaded. (That's my guess at least.)

Maybe that's not considered even a bug then, and not quite sure how easy it would be to fix. It would at least require a forward-look to check whether a dependent object about to be constructed will also get an Symbolic InputBox. And if does, the object needs to be constructed with the type it had before (that info is in the savefile). And in case the loading routine doesn't have the tools to set the type of the object upon construction, then some temporary dummy construction might be able to get the desired type-safety.


How to circumvent the issue for now? One possibility would be to simply not save the file in such a state, but not only is this hard to not accidently do it anyway, but sometimes it's even desired to save the file in such state. (For example, in the LPP file here I would want to have pre-set standard inequalities 'x≥0' and 'y≥0', but I also want GeoGebra to still consider them of the type "inequality in both x and y" or else the construction breaks (without any other special treatment). The other way to circumvent the issue is using an init script that temporarily redefines things (see attached). Overall somewhat inconvenient though.


PS: Is there a proper way to get the actual value of 'Z' via JavaScript? The string that 'getValueString' returns already has rounding rules applied (and maybe other stuff), so it's potentially not accurate. And 'getDefinitionString', 'getCommandString' are empty. (Not quite sure what they are supposed to give anyway, probably only relevant for other types of objects). As a workaround I got the text from the InputBox (which surprisingly only worked with 'getLaTeXString'), but then I couldn't find a way to set the content of the InputBox via script, so I used the string to redefine 'Z' instead. That worked here, but only because the InputBox is not set to 'Symbolic' (so there aren't LaTeX commands in the string).

photo
© 2021 International GeoGebra Institute