Sure. Sorry, excuse my phrasing; that’s what I meant but didn’t express
clearly!
Ciao,
Mike
Sent from my iPad
> On 10 Jan 2022, at 03:21, Pierpaolo Bernardi wrote:
>
>> Il giorno 9 gennaio 2022, alle ore 20:56, 'Michael Day' via Programming
>> ha scritto:
>>
>> Chat really, but I think
Well, I was using my right hand/ lh/ 2 fingers & thumb, a la Faraday, for
insight!
Didn’t help!
Mike
Sent from my iPad
> On 10 Jan 2022, at 04:54, Raul Miller wrote:
>
> I should perhaps clarify -- since there's no actual physical
> coordinates involved here. I am using "left handed" and "ri
Thanks Henry and Raul for your responses.
Indeed, I have encountered limitations of floating point arithmetic.
showmismatch is great idea to quickly detect cases validating property.
Usually I will want to have something like this though (100 runs or so):
run=: 3 : 0
shape=.1+?2#100
m=.genU
It's comparison tolerance that I think you would want to mess with, to
minimize the occurrences of this issue.
https://www.jsoftware.com/help/dictionary/dx009.htm
But you're not going to be able to set it higher than 9!:19]1e_12
If you are not concerned with floating point, though, you might wan
On Mon, 10 Jan 2022, Raul Miller wrote:
But you're not going to be able to set it higher than 9!:19]1e_12
...though of course, there's no reason you couldn't substitute your own
comparison function with a laxer tolerance. And in particular, for
small-magnitude numbers, an absolute or hybrid
On Mon, Jan 10, 2022 at 7:18 AM Elijah Stone wrote:
> ...though of course, there's no reason you couldn't substitute your own
> comparison function with a laxer tolerance. And in particular, for
> small-magnitude numbers, an absolute or hybrid comparison strategy may be
> appropriate.
Sure, but
On Mon, 10 Jan 2022, Raul Miller wrote:
x:
Good point. I was thinking that they might want to represent irrationals.
But I guess that doesn't matter so long as the properties being tested are
not tested on functions that produce irrationals.
-E
---
Even there, floating point numbers are just approximations of
irrationals, and x: works on those approximations just fine.
The limitations of x: are (1) performance -- you take a performance
(and memory) hit using arbitrary precision representation, and (2)
complex numbers. We currently do not hav
a=. x:1p1
a =!.0 ^.^:_1 ^.a
0
This is what I mean when I say 'the properties being tested are not tested
on functions that produce irrationals'. We are unable to demonstrate that
a = f^:_1 f a, because even if a is represented exactly, f may be
approximate.
-E
On Mon, 10 Jan 2022, R
Main insight here was that with any beacon being scanned from scanners 0
and s it holds that b₀ = Tₛ + bₛ*Rₛ with b₀, bₛ being the beacons
coordinates relative to 0, s resp., Tₛ is s' translation vector and Rₛ the
cube rotation matrix belonging to s.
This means Tₛ = b₀ - bₛ*Rₛ and we can calculat
Thanks for this and for the previously undefined "cross" in another post.
I now see why I got 48 rotations rather than 24 - I hadn't taken on board
that all scanners used the "same" coord system, which others have
interpreted
as all using the same parity.
You mentioned looking for 67 or 68 of
True, but that is not an example of the kind of test being performed here.
Thanks,
--
Raul
On Mon, Jan 10, 2022 at 10:08 AM Elijah Stone wrote:
>
> a=. x:1p1
> a =!.0 ^.^:_1 ^.a
> 0
>
> This is what I mean when I say 'the properties being tested are not tested
> on functions that produ
Hmm...
I like your use of reference rotations R. And, your approach to
combining what were a bunch of different steps in mine looks nice. (It
takes a bit longer this way, but for this puzzle the extra time I
needed to code up my approach is far more of a problem.)
But how did you come up with 12
On Mon, Jan 10, 2022 at 1:17 PM 'Michael Day' via Programming
wrote:
> You mentioned looking for 67 or 68 of the same beacon distances. My
> criterion was >: 66, iirc, since 12 matching distinct points would have
> 66 = 11.12%2 pairs of non-zero distances.
Actually, I was looking for at least
23? I did that one in C++. Shame on me...
On Thu, Jan 6, 2022 at 12:47 PM 'Mike Day' via Programming <
[email protected]> wrote:
> First half of 23 for me - haven’t seen the light yet!
> M
>
> Sent from my iPad
>
> > On 6 Jan 2022, at 19:38, Raul Miller wrote:
> >
> > Personally, I have
Thanks for the tolerance hint. It helps a lot indeed:
9!:18 ''
5.68434e_14
9!:19 ]1e_11
9!:18 ''
1e_11
data=:(_100 100 runiform 1);((genUniformMatrix 50 50),:(genUniformMatrix
50 50))
leftR=: 4 : '(0{x) * ( (0{y) + (1{y) )'
rightR=: 4 : '( (0{x) * (0{y) ) + ( (0{x) * (1{y) )'
On Mon, Jan 10, 2022 at 4:01 PM Pawel Jakubas wrote:
> Could you elaborate what is idea behind *x:* ? I kinda missed the point
> (please excuse me - I am just beginning my adventure with J)
x: converts the value(s) to an exact representation
https://www.jsoftware.com/help/dictionary/dxco.htm
S
https://adventofcode.com/2021/day/21
For day 21, we played a "dice game" with two chess pawns.
The game was a two player game, with a track with 10 positions,
labeled 1 through 10, and the data for the puzzle was the player's
starting positions.
example=:{{)n
Player 1 starting position: 4
Player
Perhaps we’re not talking about the same thing. I was using this bit of the
problem description:
“By finding pairs of scanners that both see at least 12 of the same beacons,
you can assemble the entire map”
So for each scanner I found its inter-beacon distances, which are independent
of th
Ah, I somehow had overlooked that part of the puzzle.
Thanks,
--
Raul
On Mon, Jan 10, 2022 at 6:29 PM 'Mike Day' via Programming
wrote:
>
> Perhaps we’re not talking about the same thing. I was using this bit of the
> problem description:
> “By finding pairs of scanners that both see at leas
Part 1 was relatively easy, but I was annoyed that I couldn’t see how to
exploit its cyclic nature. Here’s a comment to self from my script:
“ m10 +/\"1}."1 |: 15 2 $+/|:30 3$die
4 6 6 4 10 4 6 6 4 10 4 6 6 4
3 4 3 10 5 8 9 8 5 10 3 4 3 10
NB. Players 1 2 score 60 65 respectively every 10
Your 10&|&.<: is probably more comprehensible than my 11 |&.<:
But for part B, how did you handle the smearing of scores that
resulted from those new positions and counts?
Thanks,
--
Raul
On Mon, Jan 10, 2022 at 7:07 PM 'Mike Day' via Programming
wrote:
>
> Part 1 was relatively easy, but I
I finally got around to working on this again. This problem features
prominently in today's NYCJUG (spoiler alert):
https://code.jsoftware.com/wiki/NYCJUG/2022-01-11 .
On Fri, Oct 15, 2021 at 11:48 AM Skip Cave wrote:
> Brute Force probability of a pair in 5 cards:
>
> (+/%#)4=;#&.>~.&.>{(5 co
23 matches
Mail list logo
