Inequalities in LPP

Mathmagic,

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

Got it.

Saludos.

Dear Mathmagic,

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

I can not open your file

some very long conditions have a problem

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.

you can make a numeric evaluation

true = 1, false=0

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

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

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

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

Dear mathmagic,

This is not working. Will you please explain?

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.

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), "," ,"&&")})

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

thanks for the idea

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

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?

@artydent

This is how your algorithm works in my applet:

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}))

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

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.

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

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

Thank you

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.

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

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

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.

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.

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.

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

Hm,

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

Ich allerhand rumgemacht an den Nebenbedingungen...

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.

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 ;-).

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. ;-)

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 ;-)

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?

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.

@artydent @hawe

Both of you kindly upload your final ggb file.

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

Z=0 redefine Z

0=Z creates an implicit plot or line

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.

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

Will you help me to complete my problem without debugging?

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

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.

@artydent

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

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):

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

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.

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

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

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.

Definiciones circulares según me parece

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.

@mathmagic

Working fine, right!

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.

clic in cb5

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

Sorry it is ok (with last version 634)

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.

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.

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

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

constline was of type Implicit Function

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

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