Somehow, 1⎕TF is slightly slower (see the 2nd and the 3rd rows in the following)
tio¨1E5×⍳5
⍕619 ⍕1306 ⍕2007 ⍕2605 ⍕3425
1⎕tf 230 1⎕tf 461 1⎕tf 819 1⎕tf 1094 1⎕tf 1383
⍎158 ⍎ 327 ⍎ 562 ⍎ 695 ⍎
> On Jun 16, 2016, at 8:09 AM, Juergen Sauermann
> wrote:
>
> Hi,
>
> dyadic ? needs a set for filtering out already produced values (the result
> must
> not return duplicate random numbers).
>
> The DOMAIN error is thrown if the size of the set (= right argument of ?)
> becomes
> too large
Hi Xiao-Yong,
the problem with the *scanf() *(and also with the *printf()*) functions
is that text of numbers
is different from APL, for example *-* vs. *¯*, complex numbers, etc.
I therefore believe it would be more useful to have a *⎕CR* variant that
avoids full
parsing and execution of its
Hi,
dyadic ? needs a set for filtering out already produced values
(the result must
not return duplicate random numbers).
The DOMAIN error is thrown if the size of the set (= right
argument of ?) becomes
too large (and not, I believe, by
I concurs,
f←(1?2*48)÷1333.3
DOMAIN ERROR
f←(1?2⋆48)÷1333.3
^ ^
f←(1?2*32)÷1333.3
DOMAIN ERROR
f←(1?2⋆32)÷1333.3
^ ^
f←(1?2*31)÷1333.3
DOMAIN ERROR
f←(1?2⋆31)÷1333.3
^ ^
f←(1
Hi Jürgen,
Just realized my script got much slower (⍕ on a few million numbers from a text
file) with these changes. Since you have printf in ⎕FIO, can you please add
scanf, fscanf, and strto* functions to ⎕FIO, too?
In addition, the tokenizer seems to be confused with exponents.
1E9
10
Yes, they work. Thanks.
> On Jun 11, 2016, at 9:29 AM, Juergen Sauermann
> wrote:
>
> Hi Xiao-Yong,
>
> thanks, fixed in SVN 740. I haven't checked )DUMP and )OUT but I suppose
> they work now since the fault was in the tokenizer (which is also used by
> )LOAD and )IN).
>
> /// Jürgen
>
>
Hi Xiao-Yong,
thanks, fixed in SVN 740. I haven't checked )DUMP and )OUT
but I suppose
they work now since the fault was in the tokenizer (which is also
used by
)LOAD and )IN).
/// Jürgen
On 06/10/2016 10:34 PM, Xia
Hi Jürgen,
Thanks. I found more floating point reproduction issues.
⎕PP←17
x-y←x←○3 4
0 0
x-⍎⍕x
0 1.7763568394002505E¯15
x-¯14⎕CR 14⎕CR x
0 0
2⎕TF 2⎕TF ‘y'
y
y
9.4247779607693793 12.566370614359172
x
9.4247779607693793 12.566370614359172
x-○3 4
0 0
Hi Xiao-Yong,
OK - SVN 739.
/// Jürgen
On 06/07/2016 08:16 PM, Xiao-Yong Jin
wrote:
Hi Jürgen,
Thanks, though the current behavior still does not give the exact number bit by bit. Can you change it to %.17g, or std:
Hi Jürgen,
Thanks, though the current behavior still does not give the exact number bit by
bit. Can you change it to %.17g, or std::numeric_limits::max_digits10?
In addition, is it OK to raise the maximum allowed ⎕PP to 17?
Best,
Xiao-Yong
> On Jun 7, 2016, at 12:37 PM, Juergen Sauermann
>
Hi Xiao-Yong,
thanks, fixed in SVN 738.
/// Jürgen
On 06/07/2016 08:13 AM, Xiao-Yong Jin
wrote:
Hello,
Is the following behavior intended? Note the x value after load.
)clear
CLEAR WS
x←.123456789012345
12 matches
Mail list logo