Advent of code day 12

Advent of code day 12

[Stephen Leake]

simplest puzzle yet; part 2 completed without any edits!
-- 
-- Stephe

Re: Advent of code day 12

[John Perry]

On Saturday, December 12, 2020 at 2:28:30 PM UTC-6, Stephen Leake wrote:
> simplest puzzle yet; part 2 completed without any edits! 
> -- 
> -- Stephe

I mostly agree, but I had trouble with today's puzzle. It's a recurring problem of mine: if the input is not specified completely, I have trouble figuring out what it is, even when I study it, so I often get subtle bugs. And there's a LOT of input. In my input, a turn of 270 degrees doesn't show up until line 85, so I didn't see it even after scanning the file (which I did because I wanted to make sure it had integer-only positions and the turns were multiples of 90). Once I figured that out, it was quite easy.

I guess the moral of the story is that I need to think more carefully about what come through the input, as well as rely more on validating that the input meets my expectations.

Re: Advent of code day 12

[Maxim Reznik]

I used interface and tagged types to make solution more interesting :)

https://github.com/reznikmm/ada-howto/blob/advent-2020/md/12/12.md

Re: Advent of code day 12

[Gautier Write-Only Address]

> I mostly agree, but I had trouble with today's puzzle. It's a recurring problem of mine: if the input is not specified completely, I have trouble figuring out what it is, even when I study it, so I often get subtle bugs. And there's a LOT of input. In my input, a turn of 270 degrees doesn't show up until line 85, so I didn't see it even after scanning the file (which I did because I wanted to make sure it had integer-only positions and the turns were multiples of 90). Once I figured that out, it was quite easy. 

If you include all possible angles you don't encounter that issue :-)

https://github.com/zertovitch/hac/blob/master/exm/aoc/2020/aoc_2020_12.adb

Re: Advent of code day 12

[Jeffrey R. Carter]

On 12/13/20 2:33 AM, John Perry wrote:
> On Saturday, December 12, 2020 at 2:28:30 PM UTC-6, Stephen Leake wrote:
>> simplest puzzle yet; part 2 completed without any edits!
>> -- 
>> -- Stephe
> 
> I mostly agree, but I had trouble with today's puzzle. It's a recurring problem of mine: if the input is not specified completely, I have trouble figuring out what it is, even when I study it, so I often get subtle bugs. And there's a LOT of input. In my input, a turn of 270 degrees doesn't show up until line 85, so I didn't see it even after scanning the file (which I did because I wanted to make sure it had integer-only positions and the turns were multiples of 90). Once I figured that out, it was quite easy.

I had to look up the equations for rotation around the origin, but other than 
that it was simple.

I used grep to inspect the input to verify its characteristics.

-- 
Jeff Carter
"IMHO, Interfaces are worthless."
Randy Brukardt
117

Re: Advent of code day 12

[Gautier Write-Only Address]

> I used interface and tagged types to make solution more interesting :) 

Cool!
I was a bit disturbed by the code duplication around the ship's position and the Manhattan_Distance function.
Here is and idea to address it:

package Day_12 is

   package Controls is
      type Control_Interface is limited interface;
      procedure Move
        (Self  : in out Control_Interface;
         North : Natural := 0;
         South : Natural := 0;
         East  : Natural := 0;
         West  : Natural := 0) is abstract;
   
      procedure Turn
        (Self  : in out Control_Interface;
         Left  : Natural := 0;
         Right : Natural := 0) is abstract;
   
      procedure Forward
        (Self  : in out Control_Interface;
         Value : Positive) is abstract;
   
      function Manhattan_Distance (Self : Control_Interface) return Natural
        is abstract;
   end Controls;

   package Basic_Ships is

      type Position is record
         East  : Integer;
         North : Integer;
      end record;
   
      type Basic_Ship_Data is abstract new Controls.Control_Interface with record
         Ship : Position;
      end record;
   
      function Manhattan_Distance (Self : Basic_Ship_Data) return Natural;
   
   end Basic_Ships;

   package Part_1 is
   
      type Ship_Data is new Basic_Ships.Basic_Ship_Data with record
         Angle : Integer := 0;
      end record;

      procedure Move
        (Self  : in out Ship_Data;
         North : Natural := 0;
         South : Natural := 0;
         East  : Natural := 0;
         West  : Natural := 0);
    
      procedure Turn
        (Self  : in out Ship_Data;
         Left  : Natural := 0;
         Right : Natural := 0);
    
      procedure Forward
        (Self  : in out Ship_Data;
         Value : Positive);

   end Part_1;

   package Part_2 is
   
      type Ship_Data is new Basic_Ships.Basic_Ship_Data with record
         Waypoint : Basic_Ships.Position := (East => 10, North => 1);
      end record;

      procedure Move
        (Self  : in out Ship_Data;
         North : Natural := 0;
         South : Natural := 0;
         East  : Natural := 0;
         West  : Natural := 0);
    
      procedure Turn
        (Self  : in out Ship_Data;
         Left  : Natural := 0;
         Right : Natural := 0);
    
      procedure Forward
        (Self  : in out Ship_Data;
         Value : Positive);

   end Part_2;

end Day_12;

Re: Advent of code day 12

[John Perry]

On Sunday, December 13, 2020 at 3:14:30 AM UTC-6, gautier...@hotmail.com wrote:
> > I mostly agree, but I had trouble with today's puzzle. It's a recurring problem of mine: if the input is not specified completely, I have trouble figuring out what it is, even when I study it, so I often get subtle bugs. And there's a LOT of input. In my input, a turn of 270 degrees doesn't show up until line 85, so I didn't see it even after scanning the file (which I did because I wanted to make sure it had integer-only positions and the turns were multiples of 90). Once I figured that out, it was quite easy.
> If you include all possible angles you don't encounter that issue :-) 
> 
> https://github.com/zertovitch/hac/blob/master/exm/aoc/2020/aoc_2020_12.adb

Yes, I had looked at your code (and Max's) after finishing mine but before replying here, so I was aware of it at the time. That is definitely one way to avoid the issue :-) but I don't think you can use the approach I used in that case, of which I am perhaps far too fond:

   Left_Turn: array( Direction_Value, Direction_Delta ) of Direction_Value :=
   (
          ( West,  South, East  ),   -- 90, 180, 270 from north
          ( East,  North, West  ),   -- ...from south
          ( North, West,  South ),   -- ...from east
          ( South, East,  North )    -- ...from west
   );
   
so the code to perform a left turn is

   Direction := Left_Turn(Direction, D);

john perry

Re: Advent of code day 12

[John Perry]

On Sunday, December 13, 2020 at 12:40:35 AM UTC-6, Maxim Reznik wrote:
> I used interface and tagged types to make solution more interesting :) 
> 
> https://github.com/reznikmm/ada-howto/blob/advent-2020/md/12/12.md

Yes, I look at all the solutions listed on your Advent of Code page at GitHub because I appreciate interesting answers, thank you. :-)

This reminds me, though; you declare the Controls package, but in both Part_1 and Part_2 you use "overriding" only on the Move procedure, not on any other. I'm not familiar with interfaces yet; is there a reason you used that word there and nowhere else?

Re: Advent of code day 12

[Maxim Reznik]

Take a look at Ada 2005 Rationale:
https://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html

The `overriding` specification is optional only to keep backward compatibility with Ada 83/95. Usage of this keyword prevents you from errors, when you expect some function to override another from the parent type, but occasionally it doesn't. For instance, if one day you rename 'Turn' on interface type to, say, `Rotate`, without `overriding` keyword the program still compiles, but won't work as expected. So `overriding` must be :)


воскресенье, 13 декабря 2020 г. в 17:41:27 UTC+2, john....:
> On Sunday, December 13, 2020 at 12:40:35 AM UTC-6, Maxim Reznik wrote: 
> > I used interface and tagged types to make solution more interesting :) 
> > 
> > https://github.com/reznikmm/ada-howto/blob/advent-2020/md/12/12.md
> Yes, I look at all the solutions listed on your Advent of Code page at GitHub because I appreciate interesting answers, thank you. :-) 
> 
> This reminds me, though; you declare the Controls package, but in both Part_1 and Part_2 you use "overriding" only on the Move procedure, not on any other. I'm not familiar with interfaces yet; is there a reason you used that word there and nowhere else?

Re: Advent of code day 12

[John Perry]

On Sunday, December 13, 2020 at 12:36:00 PM UTC-6, Maxim Reznik wrote:
> Take a look at Ada 2005 Rationale: 
> https://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html 
> 
> The `overriding` specification is optional only to keep backward compatibility with Ada 83/95. Usage of this keyword prevents you from errors, when you expect some function to override another from the parent type, but occasionally it doesn't. For instance, if one day you rename 'Turn' on interface type to, say, `Rotate`, without `overriding` keyword the program still compiles, but won't work as expected. So `overriding` must be :) 

I think you misunderstood my question: you didn't use `overriding` on `Turn`, only on `Move`. Why only on `Move`?

Re: Advent of code day 12

[Stephen Leake]

Maxim Reznik <reznikmm@gmail.com> writes:

> Take a look at Ada 2005 Rationale:
> https://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html
>
> The `overriding` specification is optional only to keep backward
> compatibility with Ada 83/95.

I find 'overriding' useful for all tagged types; I always use -gnatyO in
my gnat compiler options. That requires 'overriding' wherever it is
allowed. That makes it very clear what operations are being overridden
for derived types.

-- 
-- Stephe

Re: Advent of code day 12

[Maxim Reznik]

> I think you misunderstood my question: you didn't use `overriding` on `Turn`, only on `Move`. Why only on `Move`?

I just forgot and didn't have `-gnatyO` in compiler options :(