Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Rätselecke » Geometrie Rätsel
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 < [ 2 ]
000
07.12.2006, 16:42 Uhr
~absoluter anfänger
Gast


Folgende Aufgabe will mal wissen ob ihr auf die Lösung kommt. Ich musste leider passen.

Gegeben sei ein regelmäßiges 2007-Eck.
Die natürlichen Zahlen 1, 2, ..., 4014 sollen so auf seine Eckpunkte
und Seitenmittelpunkte verteilt werden, dass für jede Seite die Summe
der drei Zahlen, die an den Eckpunkten und am Mittelpunkt der
Seite stehen, den gleichen Wert hat.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
07.12.2006, 18:26 Uhr
mmc20
puss in boots


mh, ich wollte mir das gerade mal aufmalen, um es besser vor augen zu haben, aber irgendwie hab ich wohl meine 2007-eck-schablone verlegt...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
07.12.2006, 21:10 Uhr
Lensflare
C++:
#include <stdio.h>

int main()
{
      const int n = 8; //Anzahl Zahlen (= Anzahl Ecken * 2)
    
      int k[n];
      int e[n/2];
      
      for(int i=0; i < n; i++)
        k[i] = 0;
    
      bool end = false;
      while(!end)
      {
        int a = 0;
        for(int p = 0; p <= n-1; p++)
          for(int q = 0; q <= n-1; q++)
            if(k[p] == k[q]) a += 1;
          
        if(a == n)
        {
          bool eq;
          
          for(int r = 0; r <= n-1; r++)
          {
            int j = 0;
            
            for(int i=0; i < n/2; i+=1)
            {
              e[i] = k[j]+k[j+1]+k[j+2==n?0:j+2];
              j += 2;
            }
            
            eq = true;
                        
            for(int i=0; i < (n/2)-1; i+=1)
              if(e[i]!=e[i+1]) eq = false;
            
            if(eq)
              printf("%i ",k[r]+1);
          }
          
          if(eq)
            printf("\n");
        }

        k[n-1] += 1;
        
        for(int j = n-1; j >= 0; j--)
          if(k[j] == n)
          {
            k[j] = 0;
            if(j > 0) k[j-1] += 1;
            else end = true;
          }
      }
      
      printf("\nfertig");
      getchar();
}


Das Programm gibt die Zahlen nacheinander im Kreis beginnend bei einer Ecke aus.
Es gibt mehrere Möglichkeiten.
Ich habe ein Paar Stichproben gemacht, es müsste also stimmen.
Jetzt brauche ich nur noch einen Rechner der schnell genug ist, das für 2007 Ecken zu berechnen
Denn bei 4 Ecken dauert es schon mehrere Sekunden. (Kein Wunder bei der gigantischen Anzahl an Kombinationsmöglichkeiten )
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
Dieser Post wurde am 07.12.2006 um 21:39 Uhr von Lensflare editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
07.12.2006, 22:33 Uhr
~absoluter anfänger
Gast


respekt respekt
in 4h 28 min
hast du das programm in der zeit geschrieben (oder in weniger benötigter zeit) oder hast du das schon fertig vorgefunden.
kann es allerdings sein das mein computer (uralt wirklich alt) den code schon bei 5 ecken (n=10) schon nicht mehr berechnen kann oder an was liegt das?
bei 4 ecken schafft der das schon bei ~4-6 sekunden.
bei 5 ecken kommt einfach nix auser ein leeres fenster und einem rechnenten computer.

allerdings dachte ich da eher an eine logische abfolge der 4014 zahlen oder kann man die nicht bestimmen? ist das bei jedem vieleck anders?
bin schon seit ner weile daran das selbe was du geschrieben hast für ein 5-eck zu schreiben aber da happerts schon ne weile und nachdem ich deine lösung gesehen hab weiß ich das da noch lange davon entfernt bin.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
07.12.2006, 22:37 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


naja das gibt etwas blödsinn aus, soll ja wenn ich das richtig verstehe folgendes:



Code:
A X X X B X X X C
X x x x x x x x X
X x x x x x x x X
X x x x x x x x X
D x x x x x x x E
X x x x x x x x X
X x x x x x x x X
X x x x x x x x X
F X X X G X X X H


so dass gilt:


Code:
A+B+C = k
A+D+F = k
C+E+H = k
F+G+H = k
k = konst
k, A bis H elem |N



in dem n=4 Fall also die nat. Zahlen von 1 bis n*2 (=8).

mehr nicht.

d.h du kriegst pro Seite ja "nur" 3 Zahlen raus, bei dir bekomme ich kein stimmiges 8-Eck.

Ansonsten schaut das trotz allem nach Mathematik-Knobelhausaufgabe aus ;)
--
class God : public ChuckNorris { };
Dieser Post wurde am 07.12.2006 um 22:38 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
07.12.2006, 23:13 Uhr
Windalf
Der wo fast so viele Posts wie FloSoft...
(Operator)


Beware...

Brutforce ist natürlich Blödsinn. Sinnvoller ist es den Grips zu benutzen...
Man brauch das einfach nur mal für 3,5,7 usw. probieren und kommt ziemlich schnell drauf wie der Hase läuft...

Man muss sich zunächst klar machen, dass es bei der Summenbildung auf die Ecken ankommt. Man muss also so geschickt die Zahlen auf die Ecken verteilen, das man am Ende kein Problem hat die restlichen Zahlen auf die Seiten zu legen.

Mit folgendem Algo geht das ganz einfach:

1) Nimm eine beliebige Ecke und schreib da die 1 ran.
2) Hopse 2 Ecken weiter und schreib da die nächsthöhere ungerade Zahl dran bis alle ungeraden Zahlen (und damit auch alle Ecken) vergeben sind...
3) Nun kann man ganz einfach die gerade Zahlen verteilen weil die Summe über die Ecken immer mit einem Delta von 2 steigt

Bauen wir das Rätsel aber doch mal weiter aus. Angenommen man verfährt noch obigen Algorithmus. Was gilt für die Summe einer Seite in Abhängigkeit von n (n ist die ungerade Anzahl an Ecken)...


Ob man die Sache mit nem Trick auch für gerade n hinbekommt weiß ich nicht. Ist mir auf die schnelle auch nichts eingefallen. Ich würde vermuten es geht nicht.

Beweisen kann ich den Krempel den ich behaupte nicht, aber ich bin ja auch Ing und kein Mathematiker. Meine Vorgehensweise ist probiere es für 1,2,3 usw... und dann glaub ich einfach das ich richtig liege


Bearbeitung von windalf:

Ach so hatte ich ganz vergessen: Bin ich gut oder bin ich gut?


--
...fleißig wie zwei Weißbrote
Dieser Post wurde am 07.12.2006 um 23:49 Uhr von Windalf editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
08.12.2006, 08:23 Uhr
FloSoft
Medialer Over-Flow
(Administrator)



Zitat von Windalf:
Ach so hatte ich ganz vergessen: Bin ich gut oder bin ich gut?


Ne biste nicht, du bist "fleißig wie zwei Weißbrote"!
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
08.12.2006, 10:26 Uhr
Windalf
Der wo fast so viele Posts wie FloSoft...
(Operator)


Das eine schliesst das andere ja nicht aus

War übrigens die falsche Antwort auf die Rätselfrage
--
...fleißig wie zwei Weißbrote
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
08.12.2006, 10:37 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)



Zitat von Windalf:
Meine Vorgehensweise ist probiere es für 1,2,3 usw... und dann glaub ich einfach das ich richtig liege


Jeder Mathematiker würde dich dafür erschlagen
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
08.12.2006, 12:34 Uhr
Lensflare



 @FloSoft:

Du hast es anders verstanden. Das Programm gibt die Zahlen in der Reihenfolge aus, in der man sie ab der ersten Ecke des Polygons kreisförmig ablegt.

Jede Zeile ist eine Variante der möglichen Zahlenfolgen.

also: wenn n = 8, dann sind es 4 Ecken und dann gibt es 8 Zahlen pro Zeile.

@~absoluter anfänger:

Zitat:

hast du das programm in der zeit geschrieben (oder in weniger benötigter zeit) oder hast du das schon fertig vorgefunden.

Ich habe es selbst geschrieben.
Aber die Lösung habe ich nicht so Ernst gemeint, weil mein Programm ja eigentlich alle möglichen Kombinationen dieser Zahlen durchläuft und dann überprüft ob die Summen an den richtigen stellen stimmen.
Deswegen dauert das so lange.

@Windalf

Zitat:

Ob man die Sache mit nem Trick auch für gerade n hinbekommt weiß ich nicht. Ist mir auf die schnelle auch nichts eingefallen. Ich würde vermuten es geht nicht.

wenn ich bei meinem Programm n=8 (4 Ecken) eingebe, dann kommt was richtiges raus und wenn ich n=10 (5 Ecken) eingebe, auch. Also gehts mit gerade und ungeraden.
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
Dieser Post wurde am 08.12.2006 um 13:28 Uhr von Lensflare editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 < [ 2 ]     [ Rätselecke ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: