HP Forums
Little explorations with HP calculators (no Prime) - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: Little explorations with HP calculators (no Prime) (/thread-7955.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


RE: Little explorations with the HP calculators - pier4r - 03-28-2017 09:32 PM

experiences using the EQW. Is the following a known bug or there is there a reason for the error? (three powers one over the other are refused, if split with parentheses , they are computed)

[Image: KMWuwK6.png]

[Image: NUbf1pJ.png]


RE: Little explorations with the HP calculators - Han - 03-29-2017 01:58 AM

Those are two very different numbers. The first one is equal to 27^27 (39 decimal digits) which is much smaller than the second number (3 638 334 640 025 decimal digits). Since each digit is a nibble (4 bits), there is not enough memory to hold all the digits.

The order of operations (due to the explicit parentheses) makes the difference.


RE: Little explorations with the HP calculators - pier4r - 03-29-2017 06:02 AM

True, I did not pay attention that parentheses work even in the exponential case. I'm doing too many basic errors, not good.


RE: Little explorations with the HP calculators - Dieter - 03-29-2017 07:54 AM

(03-28-2017 07:32 PM)Han Wrote:  
(03-28-2017 06:13 PM)pier4r Wrote:  Could you explain (or hint a known relationship) how did you get that d/2+x = d/2*sqrt(2) ?

The right picture can be worth a 1000 words, as they say :-)

Right you are!
The following picture should say it all.

[attachment=4620]

Log in and click to enlarge.

Dieter


RE: Little explorations with the HP calculators - pier4r - 03-29-2017 08:48 AM

(03-29-2017 07:54 AM)Dieter Wrote:  Right you are!
The following picture should say it all.

Neat image, which tools did you use?


RE: Little explorations with the HP calculators - Simone Cerica - 03-29-2017 09:51 AM

GeoGebra maybe --> https://www.geogebra.org/ Wink


RE: Little explorations with the HP calculators - pier4r - 03-29-2017 11:04 AM

Thanks Simone.

Anyway, following the recent pattern, I guess I'm missing something obvious here. I can determine almost all the angles but not the wanted ones.

Furthermore I do not even have a clue how can I employ the 50g to help me (until now I had some pseudo-working directions on the previous problems)

http://i.imgur.com/fWE9736.jpg

[Image: iY88oFb.png]


RE: Little explorations with the HP calculators - Han - 03-29-2017 11:31 AM

(03-29-2017 11:04 AM)pier4r Wrote:  Thanks Simone.

Anyway, following the recent pattern, I guess I'm missing something obvious here. I can determine almost all the angles but not the wanted ones.

Furthermore I do not even have a clue how can I employ the 50g to help me (until now I had some pseudo-working directions on the previous problems)

http://i.imgur.com/fWE9736.jpg

[Image: iY88oFb.png]

Have you considered the sum of the angles in a triangle and a quadrilateral, and properties of vertical angles?


RE: Little explorations with the HP calculators - pier4r - 03-29-2017 11:49 AM

(03-29-2017 11:31 AM)Han Wrote:  Have you considered the sum of the angles in a triangle and a quadrilateral, and properties of vertical angles?

Yes I considered the angles in a triangle (180) and quadrilateral (360), I considered that an angle is the same when opposite or the complementary that have a sum of 180. Unless I missed some internal shape, I got all the possibilities of which I'm aware of.

What I did see after your question is the concave pentagon. And maybe this will help.


RE: Little explorations with the HP calculators - Dieter - 03-29-2017 01:07 PM

(03-29-2017 08:48 AM)pier4r Wrote:  Neat image, which tools did you use?

This was a quick job in OpenOffice Draw, exported as PNG.

Dieter


RE: Little explorations with the HP calculators - Han - 03-29-2017 06:15 PM

(03-29-2017 11:49 AM)pier4r Wrote:  
(03-29-2017 11:31 AM)Han Wrote:  Have you considered the sum of the angles in a triangle and a quadrilateral, and properties of vertical angles?

Yes I considered the angles in a triangle (180) and quadrilateral (360), I considered that an angle is the same when opposite or the complementary that have a sum of 180. Unless I missed some internal shape, I got all the possibilities of which I'm aware of.

What I did see after your question is the concave pentagon. And maybe this will help.


So \(\angle BED\) , \(\angle BDE \), \( \angle CDE \) and \( \angle AED \) should be the only angles whose measure you cannot determine directly from the properties mentioned. What if you set up an appropriate system of equations involving these angles?


RE: Little explorations with the HP calculators - pier4r - 03-29-2017 06:35 PM

Interesting idea, again I missed that, I'll try as soon as I finish the other stuff (I just discovered DIR ... END on another thread)


RE: Little explorations with the HP calculators - Isaac S. Friedman - 03-29-2017 06:58 PM

(03-16-2017 11:06 AM)Logan Wrote:  
(03-15-2017 11:56 PM)Thomas Okken Wrote:  in fact, many such problems are notoriously difficult, for example:

find a, b, c, n such that

a^n + b^n = c^n

It's trivial to find solutions to this, but if you add these conditions:

a, b, c, n ∈ N
a, b, c > 0
n > 2

It's suddenly a lot harder. :-)

That's not hard, I could write down my marvelous little proof but this text box is too narrow. Smile

K Fermat


RE: Little explorations with the HP calculators - pier4r - 03-30-2017 08:30 AM

My Hp 50g is actually computing since 10+ hours (and I dread that it will take days to finish) so I cannot readily try the suggestions of Han.

The code, that maybe is extra unoptimized (note: I do not like to just optimize the code, it has to be also readable if I want to expand it in the future, without remembering much about it. So also readability is a factor) is the following - me trying the DIR END structure but before applying the idea of compiled local variables :


(It still has to go through some modifications, I decided to collect the results for the round robin format but, after testing for 2 repetitions, I could not imagine such lengthy process and I cannot estimate when it will finish too. So it may finish in the next minute. This is a clear example why my low quality batteries last few hours. Holy usb chargers directly from the power outlet!

If you have any tip by chance [the file is long and ugly, but it works], I'm listening Smile

Further versions, if any, will be stored here )
Code:

%%HP: T(0)A(D)F(.);
@ You may edit the T(0)A(D)F(.) parts.
@ The earlier parts of the line are used by Debug4x.

@ in npp, just select language "normal" to get rid of the highlight.

@ Objective:
@ - We want to compare the expected performances of teams of a certain
@   average strength in some types of tournaments to determine
@   what is the one that determines the best team.
@   Assuming that the best team is the one to which is given higher strength
@   a priori. Of course the simulation of the tournaments
@   should be done some times to determine the percentage of winning for each team.
@   1. round robin. Every team meets everyone else, at least twice.
@      (it could be extended with four times, six and so on)
@      Often used in long tournaments.
@      This is assumed as the best format and will be used as reference.
@   2. swiss tournament
@      Random pairings, and then teams with high score meet other teams
@      with high score, if possible avoiding pairings already done.
@      The minimum is that teams meet once.
@      Often used in chess, short but maybe effective.
@   3. knockout tournaments. Random pairing at the start and then
@      the ones that wins proceed.
@      Often used in "show tournaments", short but maybe not so effective.
@   4. only one match against all the others (like half of a round robin)
@      Often used in show tournaments. Short but maybe not so effective.

@ Remarks: the comments try to give an idea, the values in the comments may
@ be different from the actual code though.

@TODO: to pass variables between programs, try to use the compiled local variables.
@ so one does not have persistent variables after the execution.
@ Although it is not so bad to have global variables and modifying them for the next
@ trial. It is like using inputs, without having to type them on the stack.

DIR
  main    
  \<<
    0 @tmpV to use for short time, value can be changed in other functions!
    0 @tmpV2
    0 @rrResArr
    0 @rrResList (not sure what I'll use)
    \->
    @external inputs
    @local var
    tmpV
    tmpV2
    
    rrResArr
    rrResList
    \<<
      @creating/updating global variables
      @to use among programs without too much passing
      @of values
      'n*25+1200' 'n' 1 16 1 SEQ 'listTeams' STO
        @ list of teams with a priori strength score
      listTeams SIZE 'numTeams' STO
      '0' 'n' 1 numTeams 1 SEQ 'finalTournResList' STO
      
      creMatrVarProb
        @Eval not needed when calling globals
        
      1 maxTournRepV
      FOR counter      
        rrFunc
        DUP @leaving a copy of the final list of rrFunc
        
        @using the list returned by rrFunc
        updWinList
      NEXT
      
      finalTournResList
    \>>
  \>>
  
  @####################
  @creating/updating global variables
  @to use among programs without too much passing
  @of values
  
  @remark: to recall and put in local var only when speed is needed.
  
  @flag for team A winning
  uFteamAwon
  10
  
  @temp flag, not possible to expect to persist
  @in different block executions
  uFtmp
  20
  
  @flag for finding a probability
  uFmatchingProbFound
  30
  
  listTeams
  { 0 }
  
  numTeams
  0
  
  @max cumulative probability
  maxSumProbV
  0
  
  @number of possible choices or probabilties
  numProbV
  0
  
  @column for cumulative probability values
  colSumProb
  1
  
  @column for single probabilities
  colProb  
  2
  
  @column for variance result
  colVar  
  3
  
  @final matrix with cumulative probability, probability, variance results.
  mVarProb
  0
  
  @points assigned for a win
  pointsForWin
  1
  
  @repeating the same tournament type to get the winners.
  maxTournRepV
  1000
  
  finalTournResList
  0
  
  @end globals
  @####################
  
  creMatrVarProb
  \<<
    @createMatrixWithVarianceAndProbability
  
    0 @tmpV
    0 @tmpV2
    \->
    @external inputs
    @local var
    tmpV
    tmpV2
    \<<
      @ creating the matrix containing the probability of the points. Variance
      @ between -400 points and +400 points
      
      @ every drop or increment of the base strength is made in 25 points.
      @ those points have a probability. So I assign "probability tokens" at every
      @ change. For example.
      @ -400  has 25 prob tokens. -375 has 50, -350 has 75 and so on, until the
      @ base value then goes back. +25 has 400 tokens, +50 has 375 and so on.
      @ so I want to model those tokens.
      'n' 'n' 25 400 25 SEQ
      425 +
        @ expanding the previous list with 425
      'n' 'n' 400 25 -25 SEQ
        @ Or REVLIST could have been used.
      + 'tmpV' STO
        @ storing the list
        @ the complete list now goes from 25 to 425 and back to 25.
      
      @ Now we want to create the sum of all those tokens,
      @ one value for each token, We can use STREAM but we need to recall
      @ objects from the tack. I do not like stack operations because
      @ they are unreadable but when they are a few it is ok.
      @ otherwise one should comment the actions that they do.
      1 'tmpV2' STO
        @ counter, it needs to start from 1.
      tmpV 
      \<<
        @ having 25 50 75 100
        @ STREAM  25  2 Pick 25 + 25 STREAM 25 Pick 2 25 + 25  STREAM 25  Pick 2 25   + 25 
        @         50         50   75        75        75   75         75         75     75
        @                    25             75        75   150        150        150    150
        @                                             75              100        100    250
        @                                                                        150    
        2 PICK
        +
        1 'tmpV2' STO+
          @we need to count the objects that we leave on the stack. Plus 1 added at the start.
      \>>
      STREAM
        @now we have the list with all the sums
      @before making a vector out of it we save the last value that is the maximum value.  
      DUP 'maxSumProbV' STO
      @we continue      
      tmpV2
        @ the number of objects.
      \->ARRY    
        @ transformed in a vector
      
      tmpV
        @ the first list
      OBJ\->
        @ exploded
      @before saving it as vector I save the number of elements or
      @probility tokens (equals to variances)
      DUP 'numProbV' STO
      \->ARRY    
        @ transformed in a vector
        
      'n' 'n' -400 -25 25 SEQ
      0 +
      'n' 'n' 25 400 +25 SEQ
      + OBJ\->
        @ added and then exploded
      \->ARRY    
        @ transformed in a vector
      
      3 COL\-> 'mVarProb' STO
        @final matrix with columns: sum of probability tokens, probability tokens for variance, variance in points.
      
      @#########
      @output      
    \>>
  \>>

  getVarFunc
  \<<
    @program to extract the variance out of the built matrix
  
    @output, the variance of the strength points out of the matrix

    0 @curProbV
    0 @tmpV
    \->
    @external inputs
    @local var
    curProbV
    tmpV
    \<<
      maxSumProbV RAND * 1 + IP 'curProbV' STO
        @ we get a random vnumber that has to be compared with the probability sums
      
      1 'tmpV' STO
        @with tmpV we will use it as a counter
      uFmatchingProbFound CF
      WHILE
        uFmatchingProbFound FC?
        tmpV numProbV \<=
        
        AND
      REPEAT
        IF
          curProbV 'mVarProb(tmpV, colSumProb)' EVAL \<=
            @accessing the matrix in algebraic mode, slower but more readable.
            @ than the messy RPN (RPN is not always less readable, but in some cases)
            @maintenance and debug use resources as well that often are more valuable.
        THEN
          @ found a probability sum bigger than the actual random value.
          uFmatchingProbFound SF
        ELSE
          1 'tmpV' STO+
        END
      END
      
      'mVarProb(tmpV, colVar)' EVAL
    \>>
  \>>

  matchResFunc
  \<<
    @program to compute the result of a match based on the variance and probability of it.
    @ should be used by all the tournaments.
  
    0 @teamAtmpV
    0 @teamBtmpV
    \->
    @external inputs
    teamAstrV
    teamBstrV
    @local var
    teamAtmpV
    teamBtmpV
    \<<
      @In input are expected the strength of the two teams 
      @ and a user flag for the result
      @as for of variables already existing.
      @teamA
      @teamB
      @userFlagNumber
      
      @in output a flag is set
      @if teamA won, otherwise teamB
      
      uFteamAwon CF
      
      @ teamA streangth modified
      teamAstrV getVarFunc
      + 'teamAtmpV' STO
      
      @ teamB streangth modified
      teamBstrV getVarFunc
      + 'teamBtmpV' STO
      
      @there is no draw possible, at least for now.
      IF
        teamAtmpV teamBtmpV >
      THEN
        @teamA won.
        uFteamAwon SF
      ELSE
        @ teamA with lower or equal strength
        IF
          teamAtmpV teamBtmpV <
        THEN
          @teamA lost
          uFteamAwon CF
        ELSE
          @ same strength
          @ coin toss
          IF
            RAND 10 * IP
            5 <
          THEN
            @teamA won
            uFteamAwon SF
          ELSE
            @teamA lost
            uFteamAwon CF
          END
        END
      END
    \>>
  \>>

  IncListElFunc
  \<<
    @ program to increase the value of element in a list
  
    @ input on the stack see variables
    @ see the following, that if I keep adding variables on the main
    @ program it gets too unreadable.
    
    @output, the list in input, modified, on the stack
    \->
    @external inputs
    lList 
      @list
    lPosV 
      @position of the element
    lincV 
      @increase
    @local var
    \<<
      lList lPosV
        @placing list and position on the stack
        @for storing, later.
      lList lPosV GET
      lincV +
        @getting the value and increasing it
      PUT
        @putting the increasing value back
    \>>
  \>>
  
  updWinList
  \<<
    @program that updates the winner list given the
    @last tournament result list
    
    0 @maxV
    0 @tmpV
    0 @tmpList
    \->
    lastTresList
    maxV
    tmpV
    tmpList
    \<<
      uFtmp CF
        @we use it to determine if we are done
      
      lastTresList SORT REVLIST 'tmpList' STO
        @to find the maximum quickly
      
      WHILE
        uFtmp FC?
      REPEAT
        tmpList HEAD 'tmpV' STO
        
        IF
          tmpV maxV \>=
        THEN
          @valid new max
          tmpV 'maxV' STO
          
          @make tmpList smaller.
          tmpList TAIL 'tmpList' STO
          
          @increase the value in the position of the team with highest value
          @ and saving.
          finalTournResList 
          lastTresList maxV POS 
          1
          IncListElFunc
          'finalTournResList' STO
        ELSE
          @we are done
          uFtmp SF
        END
      END
    \>>
  \>>

  rrFunc
  \<<
    @program to compute a round robin tournament 
    
    0 @rrResList
    0 @teamAstrV
    0 @teamBstrV
    \->
    @external inputs
    @numTeams
    @listTeams
    @pointsForWin
    @uFteamAwon
    @local var
    rrResList
    teamAstrV
    teamBstrV
    \<<
       @program to compute a round robin tournament 
       
       @ given a list of teams with their strength and other
       @already named and set variables.
       
       @output, the list of teams with final points.
       
       '0' 'n' 1 numTeams 1
       SEQ 'rrResList' STO
         @saving the result list that at the start is just zeroes
       
       1 
       numTeams 1 -
       FOR teamPosA
         listTeams teamPosA GET 'teamAstrV' STO
           @get first team
         
         teamPosA 1 + 
         numTeams
         FOR teamPosB
           listTeams teamPosB GET 'teamBstrV' STO
             @get second team team
             
           @compute the result of a match. twice
           @as round robin requirement.
           1 2
           FOR counter
             teamAstrV teamBstrV
             matchResFunc
           
             IF
               uFteamAwon FS?
             THEN
               @update results
               rrResList teamPosA pointsForWin 
               IncListElFunc 
               'rrResList' STO
             ELSE
               @update results
               rrResList teamPosB pointsForWin
               IncListElFunc 
               'rrResList' STO
             END
           NEXT
         NEXT
       NEXT
       
       rrResList
    \>>
  \>>

@directory end
@###############################################################################​
END

@ log {
@   20:59 29.03.2017 {
@     After the discovery of the DIR END structure, I'm going to refactor the program.
@   }
@   12:05 29.03.2017{
@     Generating list of 16 teams between 1200 and 1600 strength points
@     'n*25+1200' 'n' 1 16 1 SEQ
@   }
@ }



RE: Little explorations with the HP calculators - Dieter - 03-30-2017 12:13 PM

(03-30-2017 08:30 AM)pier4r Wrote:  My Hp 50g is actually computing since 10+ hours (and I dread that it will take days to finish) so I cannot readily try the suggestions of Han.

?!? – *what* is it computing?
Obviously this in not related to the triangle problem we are discussing.

Dieter


RE: Little explorations with the HP calculators - Dieter - 03-30-2017 12:26 PM

(03-29-2017 06:15 PM)Han Wrote:  So \(\angle BED\) , \(\angle BDE \), \( \angle CDE \) and \( \angle AED \) should be the only angles whose measure you cannot determine directly from the properties mentioned. What if you set up an appropriate system of equations involving these angles?

I have tried this as well. Let <BDE = u, <BED = v, <CDE = x and <AED = y and it is possible to set up several linear equations, for instance...

u + v = 162
x + y = 111
u + x = 132
v + y = 141

...but I cannot get four independent ones, so there is no solution for a linear equation system. What do you get?

Dieter


RE: Little explorations with the HP calculators - Han - 03-30-2017 04:14 PM

(03-30-2017 12:26 PM)Dieter Wrote:  
(03-29-2017 06:15 PM)Han Wrote:  So \(\angle BED\) , \(\angle BDE \), \( \angle CDE \) and \( \angle AED \) should be the only angles whose measure you cannot determine directly from the properties mentioned. What if you set up an appropriate system of equations involving these angles?

I have tried this as well. Let <BDE = u, <BED = v, <CDE = x and <AED = y and it is possible to set up several linear equations, for instance...

u + v = 162
x + y = 111
u + x = 132
v + y = 141

...but I cannot get four independent ones, so there is no solution for a linear equation system. What do you get?

Dieter

I had not actually attempted this problem when I posed that quest. My question about considering a system of linear equations was merely that -- a question (i.e. was it tried, and does it work) -- and was not meant as an indication that I had solved it through linear systems.

You are correct, though, that the resulting system is not sufficient for solving the problem (the system does have a solution; however it appears it has an infinite number of solutions assuming we are not restricted to whole degrees for the angles).

I did eventually make some progress on this problem. I think I have a solution but I wonder if it is correct since it is not the cleanest. It is an elementary solution, but nowhere near what Paul Erdos would consider as being from "The Book." But what I ended up doing making use of the law of sines and cosines. Here's an outline of my solution.

Let F be the point along CD such that AF is perpendicular to CD. G be the intersection of the blue lines. Observe that AC and AD are equal in length. Call this length L. Use basic trigonometry determine CF (in terms of L), which then gives you CD (since CD is twice the length of CF). The law of sines applied to triangle CAE will give you the length of CE in terms of L. Then use the law of cosines in triangle CDE to determine ED (again in terms of L). Lastly, apply the law of sines to triangle CGE to determine EG in terms of L. Now you can apply the law of sines to EDG to obtain the angle GDE (which is the same as angle CDE).

I got approximately 76.32 degrees for the angle through a bit of scribbling (very likely I made a arithmetic mistake, I would imagine) and a basic scientific calculator (HP 32S).


RE: Little explorations with the HP calculators - Gerson W. Barbosa - 03-30-2017 05:47 PM

(03-30-2017 12:26 PM)Dieter Wrote:  
(03-29-2017 06:15 PM)Han Wrote:  So \(\angle BED\) , \(\angle BDE \), \( \angle CDE \) and \( \angle AED \) should be the only angles whose measure you cannot determine directly from the properties mentioned. What if you set up an appropriate system of equations involving these angles?

I have tried this as well. Let <BDE = u, <BED = v, <CDE = x and <AED = y and it is possible to set up several linear equations, for instance...

u + v = 162
x + y = 111
u + x = 132
v + y = 141

...but I cannot get four independent ones, so there is no solution for a linear equation system. What do you get?

Dieter

That's what I'd done too, but the solution is very simple, I realize now. No need to solve any linear system.

u = 72
v = 90
x = 60
y = 51

Explanation later.

Gerson.

PS: From E draw a perpendicular line to line AB, which intercepts it at F. Now we have two similar right-triangles: BEF and EFD. Angle DEF = angle EBF = 18 degrees, as we already know. Angle BDE, which you have named 'u' is its complement, 72 degrees. Finally, angle EDC, or your 'x', can be easily determined as 180 - 72 - 48 = 60 degrees.

PPS: Please do not consider this. Without any grounds I had assumed angle BED was a right angle. Fooled by my own drawing...


RE: Little explorations with the HP calculators - pier4r - 03-30-2017 06:02 PM

(03-30-2017 12:13 PM)Dieter Wrote:  ?!? – *what* is it computing?
Obviously this in not related to the triangle problem we are discussing.

Dieter

No, not to that. So during an international tournament that used the knockout format (you know, teams meet and the winner proceeds) I realized that I could compare tournaments formats somehow. (in short: pick one format as reference, assign team strength, assign variance, do the math, see who wins in the reference tournament and in the other formats)

I did a little search and I found out the swiss tournament format that is pretty neat, but I would have liked to know the statistical properties of this format compared to other formats.

I started a comparison model on paper, using the sharp el 506w as random generator (and also for multiplications). I tested two or three cases and the comparison procedure looked promising.

So I said, ok let's automate the process. But then something else happened and I put the idea aside. The other day I decided to resume the idea from my todos collection (note 1) and since I am also in a period where I'm trying to refresh and expand my user RPL / math knowledge, I decided to implement it on the 50g.

First I did it in a program with nested programs as functions (see also this topic), then I refactored it to use the newly discovered (for me) DIR ... END structure.(Pretty neat)
So I was all excited (and I still am excited) that finally I could manage better a large structure in a single file without clumsy workarounds or multiple tabs.

After some hours of coding and debugging (debugging on the hp 50g, I mean the physical one, takes time. Although I discovered a neat solution thanks to nested programs. See topic mentioned above) finally the code worked for the first tournament format. The round robin. So I did two iterations as tests and I did not detect major flaws (could still be that there are some, I hope not). So I launched 1000 iterations to get the statistics back.

I launched them at 0:56 30.03.2017 , local time. The calculator is still working (it is 20:09 local time).
My fault was that when I launched the two iterations I did not take the execution time, I was eating. So I estimated some hours of work (at the end I still usel userRPL that is heavily emulated) but now I wonder if it will be finished before the weekend. I have to rethink about the role of the hp 50g, maybe it is not so suited for such tasks unless I go for hpgcc and hpgcc-based languages (I will likely skip sysrpl).

I posted the code of the current working version of the tournament simulator in a previous post. I do not know if I missed obvious optimizations but I really thought that a tournament with 16 teams, so 240 pairings (120 pairings twice), repeated 1000 times would not take such amount of time.

It is not the first time that I end up waiting hours/day on the hp 50 though.

(note 1) About todos I do not know what the others do, but I try to collect my interesting todos. I always end up with more ideas than I'm able to process. I'm also pretty sure that there are plenty of people that have the same problem if not bigger (more todos than todos processing ability). Anyway at least I try to collect my todos, could be that someone will do it in the future.


RE: Little explorations with the HP calculators - Han - 03-30-2017 06:36 PM

(03-30-2017 05:47 PM)Gerson W. Barbosa Wrote:  That's what I'd done too, but the solution is very simple, I realize now. No need to solve any linear system.

I suspected there had to be a simple approach. I'll try your hints and also rework my solution to see where I may have made mistakes.

EDIT (after some initial thoughts):

Quote:PS: From E draw a perpendicular line to line AB, which intercepts it at F. Now we have two similar right-triangles: BEF and EFD. Angle DEF = angle EBF = 18 degrees, as we already know. Angle BDE, which you have named 'u' is its complement, 72 degrees. Finally, angle EDC, or your 'x', can be easily determined as 180 - 72 - 48 = 60 degrees.

Are you saying draw EF so that \( \angle BFE \) is 90 degrees? If so, how does it follow that triangle BEF is similar to triangle EFD without also knowing that \( \angle BED \) is 90 degrees (which does not seem obvious to me).

Or are you suggesting we make \( \angle BEF \) equal to 90 degrees? This would make it even less obvious how triangle EFD is even a right triangle.

EDIT 2: Your solution seems to suggest that we only need angles A and C. Am I missing another simple observation ?