Malb rocks:
[18:30] mabshoff|afk : actually in structs.h of Singular there
is this logic:
[18:31] #elif defined(SunOS_5)
[18:31]// #define HAVE_GENERIC_ADD
[18:31]#define HAVE_MULT_MOD
[18:31]#ifdef HAVE_MULT_MOD
[18:31]#define HAVE_DIV_MOD
[18:31]#endif
[18:34] wstein, mal
> As you can see the function pointers are off by one ... now the fun part
> begins ... why? nNULL seems correct btw.
To document the most recent results:
[16:54] #ifdef HAVE_DIV_MOD
[16:54] CARDINAL *npInvTable;
[16:54] #endif
[16:54] #if !defined(HAVE_DIV_MOD) || !defined(HAVE_
On Sunday 01 June 2008, mabshoff wrote:
> sage: P.=QQ[]
> sage: 1/x
More debugging data:
-bash-3.00$ ./sage -gdb
--
| SAGE Version 3.0.1, Release Date: 2008-05-04 |
| Type notebook() for the GUI, and licens
On May 31, 9:23 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Sat, May 31, 2008 at 12:20 PM, John Cremona <[EMAIL PROTECTED]> wrote:
> Sorry, this thread is about porting Sage to *SOLARIS*.
> The above problems are only known on Solaris. Sorry
> for not making that clearer in my post.
On Sat, May 31, 2008 at 12:20 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> 2008/5/31 William Stein <[EMAIL PROTECTED]>:
>>
>> Hi Martin and Michael,
>>
>> Here is another bit of potentially relevant debugging information related
>> to getting Sage to work on SOLARIS.
>>
>> I played around with
2008/5/31 William Stein <[EMAIL PROTECTED]>:
>
> Hi Martin and Michael,
>
> Here is another bit of potentially relevant debugging information related
> to getting Sage to work on SOLARIS.
>
> I played around with the "1/y" problem that Michael mentioned earlier.
> It turns out the following is a m
Hi Martin and Michael,
Here is another bit of potentially relevant debugging information related
to getting Sage to work on SOLARIS.
I played around with the "1/y" problem that Michael mentioned earlier.
It turns out the following is a much simpler example that illustrates
what I think is exactl
On Sat, May 31, 2008 at 6:45 AM, Martin Albrecht
<[EMAIL PROTECTED]> wrote:
>
> On Saturday 31 May 2008, Michael Brickenstein wrote:
>> No, it seems to be a computation over a finite field (else you
>> shouldn't call npPower). So
>> 0x2 is just 2 mod p.
>> Michael
>> On 31 Mai, 14:38, Martin Albre
On Saturday 31 May 2008, Michael Brickenstein wrote:
> No, it seems to be a computation over a finite field (else you
> shouldn't call npPower). So
> 0x2 is just 2 mod p.
> Michael
> On 31 Mai, 14:38, Martin Albrecht <[EMAIL PROTECTED]>
Thanks for point that out. Michael (Abshoff), may I assume y
No, it seems to be a computation over a finite field (else you
shouldn't call npPower). So
0x2 is just 2 mod p.
Michael
On 31 Mai, 14:38, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> On Saturday 31 May 2008, mabshoff wrote:
>
>
>
> > Hello folks,
>
> > I am sure the subject line will make sure tha
On Saturday 31 May 2008, mabshoff wrote:
> Hello folks,
>
> I am sure the subject line will make sure that next to no one reads
> this message, but it is important for some of us.
>
> Anyway, I finally got a pretty good lead what goes wrong when we
> compute 1/y in a MV polynomial ring on Solaris
11 matches
Mail list logo
