CAS PerpendicularVector R³-R²

hawe shared this problem 1 month ago
Not a Problem

PerpendicularVector plane R³ is deliverd as R² vector


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


change


(1) E_1:=x=0


plane ∈ R³, one of the axis planes, and PerpendicularVector(E_1) ∈ R² kills all following calculations.


I am always forced to add an R³ nul vector to hold R³


Line (5),(6)

/3zjvv6Pjx4xPQIgDthjABABgjTAAAxggTAIAxwgQAYIwwAQAYI0wAAMYIEwCAMcIEAGCMMAEAGCNMAADGCBMAgDHCBABgzCqXy6JQKBQKxaT8f17ROyjcXbRGAAAAAElFTkSuQmCC

Comments (18)

photo
1

Sorry, I think that's OK

photo
1

type x+0y+0z=0 instead x=0

photo
1

War mein erster Gedanke, aber nein das löst das Problem nicht - ich bin im CAS...

und

Michael - ich empfinde es schon als Problem, wenn aus einem 3D Objekt ein 2D Normalenvektor abgeleitet wird - wozu definiert ihr die Eigenschaft (Ebene R³) eines Objektes und sagt dann kein Problem, wenn ihr genau diese Eigenschaft nicht berücksichtigt?

photo
2

Ich sehe es ganz genauso wie hawe.


Das ist entweder falsch implementiert oder falsch dokumentiert und es ist nicht das erste Mal, das gemeldete Probleme, die ganz offensichtlich welche sind, einfach als nicht existent abgetan werden.


Die im CAS durch die drei Punkte definierte Ebene E kann gar nicht die eingezeichnete Gerade (y-Achse) sein.


/pD+UAAADsEkoDAADk9QUnQmnnnHPOOVfCCaUBINj+RXlLfygHAABgl1AaAAAgry84EUo755xzzrkS7v8BJGwBm3frkTwAAAAASUVORK5CYII= /XFF6VTp9IetKoOBKR33lk5TvXFFzkdtFrvtDd2ZfmWZanTWVkudiggmi6xCwAA2w5i1yyI3c2N3S190CrLO3ubBwbUtEkHrXT8uFRSYkfsc89Jn3225qCVfv555f26liW9+WbOB61ynfbWOpE7Y1kadlaW+V0uYmEkdgEAYNtB7JoFsftoYjdmxnf2bnDae2F0VJ15HrTKecU5j4NW6Vac9emn0t69KzGbSee3urketEqc9qaKXk+DvbJ8x1lZri8p4coyYoH9H0jxKvwQ16PGAAAAAElFTkSuQmCC


Gruß

mire2

photo
1

Sorry, I see what you mean now. The command is only implemented for Vectors in the CAS:


/P39QW+okg7Kr1u+qSo4ONiljSZllB0rwAqwAreKAuHh4SWgd+vXEjLsb5UqyflkBViB6lCAYV8dqnKYrAArwAq4mQIMezcrEE4OK8AKsALVoQDDvjpU5TBZAVaAFXAzBRj2blYgnBxWgBVgBapDAYZ9dajKYbICrAAr4GYKMOzdrEA4OawAK8AKVIcCDPvqUJXDZAVYAVbAzRRg2LtZgXByWAFWgBWoDgUY9tWhKofJCrACrICbKcCwd7MC4eSwAqwAK1AdCjDsq0NVDpMVYAVYATdTgGHvZgXCyWEFWAFWoDoUYNhXh6ocJivACrACbqYAw97NCoSTwwqwAqxAdSjAsK8OVTlMVoAVYAXcTAGGvZsVCCeHFWAFWIHqUIBhXx2qcpisACvACriZAgx7NysQTg4rwAqwAtWhAMO+OlTlMFkBVoAVcDMFGPZuViCcHFaAFWAFqkMBhn11qMphsgKsACvgZgow7N2sQDg5rAArwApUhwIM++pQlcNkBVgBVsDNFHAl7P8fMyef6U7fhVUAAAAASUVORK5CYII=

photo
photo
1

Thanks Michael,


but .... that's not the root cause, that's a consequence.


The main problem is, that CAS identifies a plane E as a line.

photo
1

The CAS "sees" only x=0 then the Algebra View has to choose whether that's a line or plane without further information. Sorry we can't improve that

photo
2

Sorry Michael,


aber wenn Du Dir endlich bitte mal die oben geposteten Bilder anschauen würdest, dann würdest Du erkennen, dass


a) die Definition der Ebene E so lautet E:=Plane( <Point>, <Point>, <Point> )

b) das CAS dann aus Plane((0,0,0),(0,1,0),(0,0,1)) lieber x=0 macht


c) das CAS dann entscheidet, dass die Ebene dann doch lieber eine Gerade sein soll


Es macht mich inzwischen hochgradig sauer, dass alles glasklar benannt, durch Bilder und angehangene Datei bestens dokumentiert ist (was soll man denn noch machen, damit das offensichtliche Problem verstanden wird?), aber man das Gefühl hat, gegen eine ignorante Wand zu reden.


Wenn jetzt immer noch die Antwort "Sorry, we can't improve that" lauten sollte, dann würde mich das doch sehr traurig stimmen.


Gruß

mire2


photo
1

Immerhin sind hier keine ehemaligen Openoffice-Entwickler eingestiegen, die hätten diesen Fall als "enhancement" eingestuft ;-), aber Deine Stimmung ist mir nicht ganz unbekannt, z.B auch:

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

photo
1

@mire2: Sorry, you are (again) making wrong assumptions about how the software works underneath. If you don't believe me then you can check for yourself: https://github.com/geogebra...

photo
1

Michael,


bitte entschuldige, dass ich jetzt nicht aufhöre zu fragen, denn das bedeutet ja auch für Dich Stress.


Ich glaube Dir durchaus, dass der Fehler möglicherweise bei mir liegt.

Das schließe ich ja prinzipiell nicht aus, aber wenn dem so ist, dann kann ich in so einem Fall doch zumindest eine Erklärung erwarten, WO bzw. WAS mein gedanklicher Fehler ist, anstatt das Ganze ohne Erläuterung einfach nur als "Kein Problem" zu markieren.

Ich glaube, dass es mich mehr kränkt und ärgert, dass mein Problem, und damit in gewisser Weise auch ich, nicht ernst genommen, sondern in gewisser Weise als erneuter naiver Bedienungsfehler meinerseits abgetan wird.


Auch Du müsstest doch angesichts des folgenden Bildes zumindest in ein leichtes Kopfschütteln verfallen.

Es kann doch im Grunde genommen nicht sein, dass ich eine Ebene durch drei Punkte aufstelle und wenn ich anschließend frage, ob die Punkte in der Ebene enthalten sind, einfach ein "false" als Antwort erhalte.

Es ist doch keine naive oder dämliche Annahme, dass man da ein "true" erwarten würde und falls das doch so sein sollte, dann müsste das doch irgendwo entsprechend dokumentiert sein und ein Verweis auf diese Dokumentation wäre beispielsweise eine hilfreiche Antwort.


Das ist doch etwas, was einen zumindest am Kopf kratzen lässt.


/8Jr0w9ch4nJnie8AGSj4D2vSHjR8wKQH+a8AFjJ928bIwE2Xn4GF+EFVA5uzAZgJcILgJUILwBWIrwAWInwAmAlwguAlQgvAFYivABYifACYCXCC4CVCC8AViK8AFiJ8AJgpbINL4qiyruc8Gpra6MoirKmnPAqF21tbcW+BAAFQHgBsBLhBcBKhBcAKxFeAKxEeAGw0v8H+ohDrgDpGLUAAAAASUVORK5CYII=


Mir ist inzwischen klar, dass das an Art und Weise liegen muss, in der das CAS Punkte behandelt, die aber nirgendwo für den Nutzer offensichtlich dokumentiert ist:


/Z1w2kpaOZLQAAAAASUVORK5CYII=


Im Algebra-Modus:


933e7da2e7f923b28c48786c4ed3f4386d6d1dcd850696feccf418ea2fc266f0

Auch scheint das CAS mit dieser speziellen Ebene durch (0,0,0), (0,1,0) und (0,0,1) Probleme zu haben, denn es gibt dann einen Normalenvektor mit lediglich zwei Komponenten, aber bei einer anderen Ebene wie gewünscht einen mit drei Komponenten aus.

Und der Befehl Normalvektor( <Ebene> ) = PerpendicularVector( <Plane> ) ist dokumentiert: https://wiki.geogebra.org/e...


7a110f7df98b6f7e77de4e9da3ed018e


Gruß

mire2

photo
1

Sorry, I've done my best to explain already. I can't spend several hours on every user report sadly


The manual isn't perfect, but complaining about it isn't the best way to get that improved

photo
photo
1

Yo también pienso que hay un bug en el comando plane() en el CAS. Si no ¿cómo se explica que la intersección de un plano con otro no esté contenida en él? Ver adjunto

Files: foro.ggb
photo
1

Sorry, that's not implemented in the CAS :(

photo
1

what? Plane( <Point>, <Point>, <Point> ) , Intersect( <Plane>, <Plane> ) or both ?

Then do the answer must be ....undefined or {} ?

nothing works with planes defined in CAS

photo
1

...accidentally put my overall comment as reply here, but am unable to delete it

photo
photo
1

The main problem seems to be that the CAS-mode (unlike the Algebra mode) doesn't actually handle geometric objects but merely the equations which might describe such objects, but without the necessary contextual information. So for the CAS mode there is no such thing as a plane, but simply an equation like "x=0" which might describe a plane in 3D but also a line in 2D or a hyperplane in higher dimension. The CAS mode is simply not designed (for some reason) to "know" this additional information.

Even though some commands are implemented in CAS mode (e.g. "Plane( <Point>, <Point>, <Point> )", the result isn't the actual object (as one might expect) but simply the equation describing it. Any contextual information (e.g. that a plane equation was contructed from 3 points in 3D) is lost in CAS mode.


And I guess that's also why several commands from the Algebra mode - e.g. "Intersect( <Object>, <Object> )" or "PerpendicularVector( <Plane> )" -aren't even implemented in CAS in the first place, because CAS "doesn't know" such objects. Although it's unfortunate that those commands don't give a warning when used with "improper" parameters. It seems that in such a case Geogebra just tries to re-interpret the arguments and uses a fitting command version from the Algebra mode or some such (just a guess from me, I haven't actually worked through the source code). This isn't necessarily a bad design (often it will do the thing the user actually wanted), but it also leads to wrong expectations on the user side and possibly to frustration when the result isn't what the user wanted.

photo
1

Then does this mean that in CAS we can use only https://wiki.geogebra.org/e... ?

I really never had problem because I avoid JS, scripts or CAS when possible

anyway, this does not justify certain calculation differences in the attachment

Files: foro.ggb
© 2021 International GeoGebra Institute