http://www.jsoftware.com/jwiki/PascalJasmin/Miller%20Rabin%20related%20code
with some updates. There were bugs in the code I posted in message.
- Original Message -
From: Raul Miller
To: Programming forum
Cc:
Sent: Tuesday, February 18, 2014 11:39:52 PM
Subject: Re: [Jprogramming] s
Thanks Roger and everyone. It's helped me improve
www.jsoftware.com/jwiki/Vocabulary/bangdot
On Thu, Feb 20, 2014 at 1:49 AM, Roger Hui wrote:
> Comparisons involving extended precision numbers are defined to be exact.
>
>
>
> On Wed, Feb 19, 2014 at 5:35 PM, Pascal Jasmin >wrote:
>
> >
> >
> >
Thanks Roger. The first line of that ref explains why.
I was treating T as an increment|decrement.
On Thu, Feb 20, 2014 at 1:24 AM, Roger Hui wrote:
> See also http://www.jsoftware.com/jwiki/Essays/Tolerant_Comparison
>
>
> On Wed, Feb 19, 2014 at 4:37 PM, Henry Rich wrote:
>
> > Comparison to
Comparisons involving extended precision numbers are defined to be exact.
On Wed, Feb 19, 2014 at 5:35 PM, Pascal Jasmin wrote:
>
>
> it gets surprising/ineffective/unnapplicable if extended numbers are used:
>
> T=: 2^_34x
>
> 2 = 2+T%2
> 0
>2 =!.T 2+ 2^_44166x
> 0
>
> Though to fix y
It is in fact right on the edge:
T=: 2^_34
2=!.T 2+T+T
1
hex=: 5 }. 2: 3!:3 ,
hex 2+T+T
4004
X=: }: 2 (3!:3) 2*1+t
X
e200
0008
0001
unhex=: 3!:2 @ (X&,)
2 =!.T unhex '4004'
1
2 =!.T unhex '4
it gets surprising/ineffective/unnapplicable if extended numbers are used:
T=: 2^_34x
2 = 2+T%2
0
2 =!.T 2+ 2^_44166x
0
Though to fix your issue:
2 =!.T 2+ 2^_35
1
2 =!.T 2+ 2^_33
1
2 =!.T 2+ 2^_32
0
- Original Message -
From: Ian Clark
To: Programming forum
Cc:
Yes, the test is very close to the edge:
T=: 2^_34
2 =!.T 2+T+T
1
2 =!.T 2+T+T+2^_50
0
Henry Rich
On 2/19/2014 8:33 PM, Roger Hui wrote:
You have to consider the definition of tolerant equality carefully. It is
the _relative_ difference that matters, not the absolute difference. Th
You have to consider the definition of tolerant equality carefully. It is
the _relative_ difference that matters, not the absolute difference. The
absolute difference between 2 and 2+T+T is 2*T, but the relative difference
is (2*T)%2+T+T, and this relative difference is less than T.
On Wed, F
See also http://www.jsoftware.com/jwiki/Essays/Tolerant_Comparison
On Wed, Feb 19, 2014 at 4:37 PM, Henry Rich wrote:
> Comparison tolerance cannot be more than 2^_34.
>
> (So that integer comparisons on 32-bit machines do not have to worry about
> tolerance)
>
> Henry Rich
>
>
>
> On 2/19/2014
Okay, I was reading that as *less* than 2^_34
All is not as it seems however...
] T=: 2^_34
5.82077e_11
2 =!.T 2+T
1
2 =!.T 2+T+T NB. I'd expect 0 here
1
2 =!.T 2+T+T+T
0
NB. at last!
On Thu, Feb 20, 2014 at 12:37 AM, Henry Rich wrote:
> Comparison tolerance cannot be more
Comparison tolerance cannot be more than 2^_34.
(So that integer comparisons on 32-bit machines do not have to worry
about tolerance)
Henry Rich
On 2/19/2014 7:03 PM, Ian Clark wrote:
I'm trying to construct an example using Fit (!.) to customize a given
primitive (e.g. =) to set its tolera
Thank you both. That's what I was looking for.
On Wed, Feb 19, 2014 at 5:52 PM, Devon McCormick wrote:
>a#~a *./ . < 10
> if you want all elements in the row to be less than 10, or
>a#~a +./ . < 10
> if you want any element in a row to be less than 10.
>
>
> On Wed, Feb 19, 2014 at 5:50
I'm trying to construct an example using Fit (!.) to customize a given
primitive (e.g. =) to set its tolerance.
Try as I might I cannot get variants of this to work:
T=: 0.001
2 =!.T 2.0001
|domain error
| 2=!.T 2.0001
What am I doing wrong?
---
a#~a *./ . < 10
if you want all elements in the row to be less than 10, or
a#~a +./ . < 10
if you want any element in a row to be less than 10.
On Wed, Feb 19, 2014 at 5:50 PM, Vijay Lulla wrote:
> (*./"1 a<10) # a
>
> maybe?
>
>
> On Wed, Feb 19, 2014 at 5:40 PM, Joe Bogner wrote:
>
> >
(*./"1 a<10) # a
maybe?
On Wed, Feb 19, 2014 at 5:40 PM, Joe Bogner wrote:
> This is an easy one, but it's escaping me after searching and trying
> several things
>
> How can I mimic this with a 2d array? I want to only return the rows the
> match a boolean expression
>
> Works
>a=: i. 10
Dear All
Please use the general forum for installation and related questions. See
http://www.jsoftware.com/jwiki/System/Forums for an overview of the forums.
Thanks.
Chris
--
For information about J forums see http://www.jsoftwar
This is an easy one, but it's escaping me after searching and trying
several things
How can I mimic this with a 2d array? I want to only return the rows the
match a boolean expression
Works
a=: i. 10
(a < 5) # a
0 1 2 3 4
Does not work the way I want...
a=:i. 5 10
a
0 1 2 3 4 5
The J version looks good.
I don't understand the problem "... there i seem to be sent to the
Microsoftee default:-(" .
What did you do and with what result?
On Thu, Feb 20, 2014 at 6:25 AM, greg heil wrote:
> >i did a fresh download and install today and the problem remains. The
> JVERS
>i did a fresh download and install today and the problem remains. The JVERSION
>was and still is
Engine: j701/2011-01-10/11:25
Library: 8.01.020
Qt IDE: 1.0.23/4.8.5
Platform: Win 64
Installer: j801 install
InstallPath: c:/l/j/j64-801
greg
~krsnadas.org
--
from: greg heil ghei...@gmail.com
to
Very interesting Henry. This seems to be a coincidental side effect of the
fact that the integer flag for booleans is less than the flag for literals
as specified here:
http://www.jsoftware.com/docs/help701/dictionary/dx003.htm
Now, I wonder if forcing the boolean to stay numeric would wreak havoc
And, I seem to have most of the major errors out of my code. I can now read
a .nif file to an internal J representation and write it back out. The
result written from the internal data structure is identical to the
original, which is a good test of the fidelity of the read/write code.
And this ref
Here's the answer:
test =: ' ' , [: {. '' , >
test a:
test <$0
|domain error: test
| test<$0
test <0$0
Henry Rich
On 2/18/2014 12:51 AM, km wrote:
Henry, experiments with 3!:3 make me guess <0$0 as a correct definition of a:
but I have no clue how to define verb test. --Ki
Thanks Devon, I can confirm this bug.
tsPlus is currently defined as:
tsPlus=: [: toDateTime@toDayNo (6&{.@[ + adjustYrMth@(_6&{.@]))"1 f.
where adjustYrMth is
adjustYrMth=. 2&}. ,~ [: ]&.:(0 12&#.) 2&{.
I think the issue can be resolved by moving adjustYrMth to after the
addition?
tsPlus=: [:
1 2 e.~ 3 3 3 4 1
0 0 0 0 1
Your three expressions are equivalent to:
0 -.@+. 0 -.@+. 0 -.@+. 0 -.@+. 1
1
0 -.@:+. 0 -.@:+. 0 -.@:+. 0 -.@:+. 1
1
-. 0 + 0 + 0 + 0 + 1
0
I see that you have already discovered this, but perhaps this perspective
will be useful for someone else?
Thanks,
sorry common mistake:
1 2 -.@:(+./)@:e.~ 3 3 3 4 1
0
- Original Message -
From: Pascal Jasmin
To: "programm...@jsoftware.com"
Cc:
Sent: Wednesday, February 19, 2014 4:34:28 PM
Subject: [Jprogramming] weird behaviour with [: vs @:
I don't understand the source of this issue:
1
I don't understand the source of this issue:
1 2 -.@+./@:e.~ 3 3 3 4 1
1
1 2 -.@:+./@:e.~ 3 3 3 4 1
1
1 2 ([: -. +./@:e.~) 3 3 3 4 1
0
The 3rd one is the "correct" intention. But I thought these were equivalent
forms.
--
I was looking at "tsPlus" from here -
http://www.jsoftware.com/jwiki/Addons/types/datetime - and noticed that
(6{.1995 12 31) tsPlus 6{.0 6
returns
1995 7 1 0 0 0
instead of
1996 6 30 0 0 0
as I would expect.
I have a (very ugly) verb "TSAdd" that I believe is mostly correct:
TSAdd=: 4 : 0
NB.
Yes, I think so...LINE is the number of consecutive black pixels.
$ (1,3)$1
1 3
I need to have it match the rank of xb to do the matching in E. (as far as
I know)
$ xb
58 157
On Wed, Feb 19, 2014 at 1:26 PM, Raul Miller wrote:
>lineStarts=:((1, LINE) $ 1) E. y
>lineEnds=: |."1
lineStarts=:((1, LINE) $ 1) E. y
lineEnds=: |."1 ((1, LINE) $ 1) E. |."1 y
(1,3)$1
1 1 1
This matches your intent? (I am not objecting, just making sure I
understand.)
Thanks,
--
Raul
On Wed, Feb 19, 2014 at 1:00 PM, Joe Bogner wrote:
> I came up with a slightly different approac
I came up with a slightly different approach that seems to work well on my
test cases so far:
http://drp.io/jsnW
xb =: 600 >: x2 NB. make 1 if less than 600 combined RGB
lineDetect=: 4 : 0
LINE=:x
lineStarts=:((1, LINE) $ 1) E. y
lineEnds=: |."1 ((1, LINE) $ 1) E. |."1 y
lD=:lineStarts+.lineEnds
On Wed, Feb 19, 2014 at 11:06 AM, Joe Bogner wrote:
> Input: http://drp.io/files/5304d74f7ba1d.jpg
> Output: http://drp.io/files/5304d7049f938.jpg
Pretty!
(Or am I just showing how warped my tastes are?)
Thanks,
--
Raul
--
Don, Jan-Pieter - Thanks for the other ideas
Raul, I will give that a shot. It looks like a much cleaner approach. Just
to prove it to myself that something was possible, I hacked together this
awful version. It works reasonably well though. Here's a version on the IRS
tax table just for fun.
Inp
I'd like to introduce you to ~:/\
~:/\ is an illustration of one of the things I really like about J. It is
equivalent to 2 | +/\ ] but without the possibility of overflow. And it
turns out to be really handy when reasoning about bit operations.
One way of describing it is as a slightly flawed se
Funny enough I was talking with a colleague about this a few days ago. We
came up with these links:
http://stackoverflow.com/questions/2596722/is-there-any-super-fast-algorithm-for-finding-lines-on-picture
or this one
http://en.wikipedia.org/wiki/Hough_transform
These tackle the more general pr
You may not be interested in a little reading on seismic convolution. This
is a process to recognize lines (horizons, changes in the propagation of
sound waves causing a reflection) in seismic data. Seismic recordings of
reflections (echoes) from a source (sound generator) to geophones (to
record t
On Wed, Feb 19, 2014 at 7:25 AM, Henry Rich wrote:
> Look at
>
> (1 10$0) E. image
>
> or
>
> (10 $ 0) E. line
>
>
Thanks Henry, that worked well. I have a version that seems to work now
(albeit clunky)
]lines=: 4 10 $ (0 0), (5 $ 1), (3 $ 0),(5 $ 1), (0 0 0), (1 1), (10 $ 1)
lineStarts=:(1 5$1)
Look at
(1 10$0) E. image
or
(10 $ 0) E. line
Beware of a previously-reported bug in non-literal E.
Henry Rich
On 2/19/2014 7:04 AM, Joe Bogner wrote:
I can get it aligned, but I'd like to flag the start of the line and not
just when I first detect a line.
For example, I'm saying a line is
I can get it aligned, but I'd like to flag the start of the line and not
just when I first detect a line.
For example, I'm saying a line is when 10 consecutive pixels are 0. This
flags the 10th pixel. When I reshape and align, I'm losing the line starts.
I apologize for the poor wording of this. P
38 matches
Mail list logo
