Hi,
thanks a lot. I believe I found it now.
The check for near-int in the complex modulo was still incorrect
(and interestingy correct in the non-complex case). SVN 937.
/// Jürgen
On 04/26/2017 09:08 PM, Peter Teeson
wrote:
> > On 04/22/2017 12:28 AM, enz...@gmx.com wrote:
> > line 13but WITHOUT ANY WARRANTY; without even the implied warranty
> > of ; -> , for oxford comma?
FWIW, it wouldn't be an Oxford comma because there isn't any kind of enumeration
here. The clause starting with "without
In which header is cval() defined?
> On Apr 26, 2017, at 3:00 PM, Kacper Gutowski wrote:
>
> On Wed, Apr 26, 2017 at 06:30:34PM +0200, Juergen Sauermann wrote:
>> For those of you that can reproduce the problem on their machine, please let
>> me
>> know if the problem has not disappeared.
>
On Wed, Apr 26, 2017 at 06:30:34PM +0200, Juergen Sauermann wrote:
> For those of you that can reproduce the problem on their machine, please let
> me
> know if the problem has not disappeared.
I just compiled 934 and 3J1|23J1 gives 3J1 for me too.
My g++ version is 6.3.0 20170415 on debian sid.
Of course….. I 100% agree.
It was just a suggestion for a differential diagnosis (in medical terms not
calculus ones).
Once log ago I had to track down an IBM Fortran 77 Floating point bug… which I
was able to do and send a PTF to them.
Never had to deal with the assembly for complex numbers so i
Hi Jay et al,
thanks for the analysis. I hope this problem is fixed in SVN
934.
For those of you that can reproduce the problem on their machine,
please let me know
if the problem has not disappeared.
/// Jürgen
O
Hi Peter et al,
I believe the proper way to fix this is to find the root cause of
it, not to find a compiler
under which the problem does not occur. I am currently following
Jays advice, but the
work on it is still ongoing.
// Jürgen
what is his processor?
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
On Wed, 26 Apr 2017 11:28:00 -0400
Peter Teeson wrote:
> Works OK on my Early 2009 Mac Pro running macOS 10.10.5 Yosemite and APL
> #svn927
>
> You have different HW but same OS & toolchain?
> So how about trying a differe
Works OK on my Early 2009 Mac Pro running macOS 10.10.5 Yosemite and APL #svn927
You have different HW but same OS & toolchain?
So how about trying a different toolchain to see if it is the compiler etc?
Or what about trying to disassemble the coded at the point of execution?
Could it be somethin
http://www.theonion.com/americanvoices/oxford-comma-wins-court-case-workers-55578
On Sat, 22 Apr 2017 16:25:52 +0200
Juergen Sauermann wrote:
> Hi,
>
> this sentence is the verbatim copy of the phrase proposed in
> https://www.gnu.org/licenses/gpl.txt
> (chapter 17) and I do not feel like c
I see the wrong result on my machine, just like Fred. Jürgen, the problem
seems to be in this code:
// if ⎕CT != 0 and B ÷ A is close to an integer within ⎕CT then return 0.
//
// Note: In that case, the integer to which A ÷ B is close is either
// floor(A ÷ B) or ceil(A ÷ B).
//
co
11 matches
Mail list logo
