Putting quotes around strings is important so you can see leading and
trailing blanks.
On Wed, Apr 13, 2016 at 1:07 PM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi,
>
> I can look into this. However, how shall we handle character arrays with
> rank > 1?
> Quotes on every line o
On Thu, Apr 14, 2016 at 1:54 AM, Xiao-Yong Jin wrote:
> Exactly so. ‘-Ofast -fno-finite-math-only’ gives correct results.
> What’s going on here? I don’t expect this has anything to do with NaN or Inf.
pow(-8., 1./3) is nan.
And -ffinite-math-only eliminates isfinite check at FloatCell.cc:422.
Exactly so. ‘-Ofast -fno-finite-math-only’ gives correct results.
What’s going on here? I don’t expect this has anything to do with NaN or Inf.
> On Apr 13, 2016, at 2:13 PM, Jay Foad wrote:
>
> I'd guess -ffinite-math-only.
>
> Jay.
>
> On 13 April 2016 at 19:36, Xiao-Yong Jin wrote:
>> Lo
Hi,
this looks more like a comma separated value list ( fds ⎕CSV Array )
fds: field delimiter string like
fds←' ",;≡'
fds[1] ←→ Numeric field quote -
alt ⊂'()' or other brackets to output (field)
fds[2] ←→ Character field quote -
alt ⊂'<>' or other brackets to output
fds[3
I'd guess -ffinite-math-only.
Jay.
On 13 April 2016 at 19:36, Xiao-Yong Jin wrote:
> Looks like a gcc optimization problem (clang works correctly).
> Using ‘-Ofast’ with gcc 5.3 reproduces the bug.
> Using ‘-O3’ works fine.
>
> So one of the options down here caused the bug:
> -fassociative-math
Looks like a gcc optimization problem (clang works correctly).
Using ‘-Ofast’ with gcc 5.3 reproduces the bug.
Using ‘-O3’ works fine.
So one of the options down here caused the bug:
-fassociative-math
-fcx-limited-range
-ffinite-math-only
-fmath-errno
-freciprocal-math
-fsigned-zeros
-ftrapping-m
Am 12.04.2016 um 13:18 schrieb Jay Foad:
> 'foobartestfootest' replace 'foo' 'xy'
Hi,
there are some corner conditions ((1↓u),⍺ contains u, but ⍺ does not):
replace←{(⍴v)↓∊(⊂v),¨(↑⍴u)↓¨(+\u⍷a)⊂a←u,⍺⊣(u v)←⍵}
'foobartestfootest' replace 'foo' 'xy'
xybartestxytest
'fo
Hi,
I can look into this. However, how shall we handle character
arrays with rank > 1?
Quotes on every line or one quote at the beginning and one at the
end (for example)?
If the problem is distinguishing numbers and characters then we
co
Hi Xiao,
interesting. I am still getting this in *SVN**719*:
* 8 ¯8⋆÷3
2 1J1.732050808*
/// Jürgwn
On 04/13/2016 03:42 AM, Xiao-Yong Jin wrote:
Hi,
With the svn version 719,
8 ¯8⋆÷3
2 0.0
but with the release version 1.5,
8 ¯8⋆÷3
2 1J1.732050808
Best,
Xiao-Yon
Hi Kacper et al,
I understand. But I would say that using ⎕EA as you
describe is exactly how
cleanup should be done. I see ⎕EA not like (as the name
may suggest) a means of
trying different paths until one succeeds like in:
'try_A' ⎕EA
I agree, and specifically I'd suggest using double quotes for an
encapsulated array of characters, while using single quotes to indicate the
difference between characters and numbers inside an array.
This would be analogous with the GNU APL extension where double quotes
ensures arrays even for sin
Off the cuff, it seems like putting quotes around strings is a really good
idea. How else would you tell the difference between 123 and "123"?
Blake
On Wed, Apr 13, 2016 at 2:34 AM, Elias Mårtenson wrote:
> Given the following expression:
>
> * 8⎕CR 2 2⍴10 'foo' 20 'bar'*
> ┌→───┐
> ↓
Given the following expression:
* 8⎕CR 2 2⍴10 'foo' 20 'bar'*
┌→───┐
↓10 ┌→──┐│
│ │foo││
│ └───┘│
│20 ┌→──┐│
│ │bar││
│ └───┘│
└∊───┘
The combination of strings and numbers in the array isn't very pretty.
I'd like to suggest that it renders as following instead:
┌→───┐
13 matches
Mail list logo