{{ }} is just a convenience.
I like it because I do not have to concern myself with doubling quotes
when using the expressions in string contexts.
Thanks,
--
Raul
On Tue, Jan 11, 2022 at 3:45 PM Pawel Jakubas wrote:
>
> Thanks Raul for all great hints (not all yet absorbed by me, for example
Thanks Raul for all great hints (not all yet absorbed by me, for example
the usage of {{ }}, but will in time, when it becomes clear to me why it is
better).
For the record. I have documented all ways suggested in this thread to have
always at my disposal:
https://github.com/paweljakubas/j-random-
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
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) )'
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
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
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
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
---
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:
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
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
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
I see several issues here.
First off, I should point out that you have some useless code in your
leftR and in your rightR implementations. These do not affect the
outcome, but do influence readability. Here's my rephrasing with that
useless code removed:
leftR=: {{
x * (0{y) + 1{y
}}
rightR=:
Dear J users,
I am testing very simple multiplication property:
s (A+B) = sA + sB
using emulated property testing (more on this here
https://github.com/paweljakubas/j-random-matrices/blob/main/chapters/algebra.md#testing-matrix-properties
)
So basically I am doing something like this:
*runiform=:
14 matches
Mail list logo
