วันพฤหัสบดีที่ 31 ธันวาคม พ.ศ. 2552

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

On Thu, Dec 31, 2009 at 10:09 PM, Tim Daly <daly@axiom-developer.org> wrote:
> William Stein wrote:
>> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly <daly@axiom-developer.org> wrote:
>> The output is used both for human use and for regression testing.  Its
>> primary use is human -- it's an example in the Sage reference manual:
>>
>>    sage: float(e)
>>    2.7182818284590451
>>
>> This is something a user will look at when reading the documentation
>> for some function.  It illustrates what happens when they convert the
>> symbolic constant e to float.
>>
>> William
>>
>>
> And therein lies the problem. We use a regression that does a comparison
> of the
> printed representation of the output of the run with a stored copy of
> the output.
>
> All of our regression tests were passing until I installed another,
> unrelated program.
> Suddenly about 30 regression tests started failing. It turns out that
> the unrelated
> program upgraded one of the system libraries. The net effect of that
> change was
> to cause the last digit in the output to "wobble" so that some of the
> table values
> differ in the nth place (20th, 30th, or thereabouts digit). This caused
> the regression
> comparisons to fail.
>
> Common lisp will give you the exact bit pattern of the float and this value
> does not wobble so the text comparison succeeds with both the old and
> the new libraries against the bit pattern.
>
> So I can tell you from experience that what you would like to do is not
> going to succeed.

What I would like to do does succeed. The goal of the doctest suite
in Sage is:

(1) to provide examples for users that illustrate every function in Sage,

(2) assure that these examples run as claimed, in the sense that a
given input pasted into the Sage command line, results in the claimed
output (with certain well-defined assumptions about state).

You can view (1) as documentation for users, and view (2) as one form
of "regression testing". There are many types of regression tests.

Regarding your example, I would consider it a bug if the specific
examples of Sage's floating point output -- as claimed in the examples
in the official documentation -- are wrong in the presence of certain
standard system-wide shared libraries. That is to say, if the Sage
documentation says:

sage: foo(bar)
1.2345

but in fact in Sage one has

sage: foo(bar)
1.2351

then I would consider this misleading documentation, i.e., a bug.
Your statement above suggests that you *don't* consider this a bug at
all. In Sage, one possible solution (and it depends on context
whether this it the right solution or not) would be to change the
documentation to

sage: foo(bar) # last few digits numerically unstable
1.23...

The "..." in Python's doctest framework is a wildcard. The Sage
code hasn't been changed, but the documentation has been. The point
is that a read of the documentation for the function foo will see
explicitly -- right there in the documentation -- that there are
numerical noise issues on certain platforms. We have followed
exactly this approach in all of the Sage example docstests, which now
total over 110,000 lines of input, testing over 19,000 functions (or
80.9% of the functions in Sage).

-- William

>
> Our solution to the human vs regression problem is to include the stable
> bit values in the actual compare and keep the human values in a latex
> table. This is easy to do with literate input.
>
> Tim
>
>
>
>
>
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

On Thu, Dec 31, 2009 at 10:09 PM, Tim Daly <daly@axiom-developer.org> wrote:
> William Stein wrote:
>> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly <daly@axiom-developer.org> wrote:
>> The output is used both for human use and for regression testing.  Its
>> primary use is human -- it's an example in the Sage reference manual:
>>
>>    sage: float(e)
>>    2.7182818284590451
>>
>> This is something a user will look at when reading the documentation
>> for some function.  It illustrates what happens when they convert the
>> symbolic constant e to float.
>>
>> William
>>
>>
> And therein lies the problem. We use a regression that does a comparison
> of the
> printed representation of the output of the run with a stored copy of
> the output.
>
> All of our regression tests were passing until I installed another,
> unrelated program.
> Suddenly about 30 regression tests started failing. It turns out that
> the unrelated
> program upgraded one of the system libraries. The net effect of that
> change was
> to cause the last digit in the output to "wobble" so that some of the
> table values
> differ in the nth place (20th, 30th, or thereabouts digit). This caused
> the regression
> comparisons to fail.
>
> Common lisp will give you the exact bit pattern of the float and this value
> does not wobble so the text comparison succeeds with both the old and
> the new libraries against the bit pattern.
>
> So I can tell you from experience that what you would like to do is not
> going to succeed.

What I would like to do does succeed. The goal of the doctest suite
in Sage is:

(1) to provide examples for users that illustrate every function in Sage,

(2) assure that these examples run as claimed, in the sense that a
given input pasted into the Sage command line, results in the claimed
output (with certain well-defined assumptions about state).

You can view (1) as documentation for users, and view (2) as one form
of "regression testing". There are many types of regression tests.

Regarding your example, I would consider it a bug if the specific
examples of Sage's floating point output -- as claimed in the examples
in the official documentation -- are wrong in the presence of certain
standard system-wide shared libraries. That is to say, if the Sage
documentation says:

sage: foo(bar)
1.2345

but in fact in Sage one has

sage: foo(bar)
1.2351

then I would consider this misleading documentation, i.e., a bug.
Your statement above suggests that you *don't* consider this a bug at
all. In Sage, one possible solution (and it depends on context
whether this it the right solution or not) would be to change the
documentation to

sage: foo(bar) # last few digits numerically unstable
1.23...

The "..." in Python's doctest framework is a wildcard. The Sage
code hasn't been changed, but the documentation has been. The point
is that a read of the documentation for the function foo will see
explicitly -- right there in the documentation -- that there are
numerical noise issues on certain platforms. We have followed
exactly this approach in all of the Sage example docstests, which now
total over 110,000 lines of input, testing over 19,000 functions (or
over 80% of the functions in Sage).

-- William

>
> Our solution to the human vs regression problem is to include the stable
> bit values in the actual compare and keep the human values in a latex
> table. This is easy to do with literate input.
>
> Tim
>
>
>
>
>
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

On 2009-Dec-31 17:50:05 -0200, Gonzalo Tornaria <tornaria@math.utexas.edu> wrote:
>gcc is actually inlining exp(1.0) to its correct value. The exp() from
>the sun library is incorrect. Try this program instead:

FreeBSD libm is derived from Sun's libm and also gets exp(1) 1ULP high
on amd64 (on i386, exp() is written using i387 assembler) so I tend to
agree that the bug is in Sun's libm.

>#include <math.h>
>#include <stdio.h>
>#include <stdlib.h>
>
>int main(int argc, char **argv) {
> double x = 1.0;
> if (argc>1)
> x = atof(argv[1]);
> printf("%.16lf\n",exp(x));
^^ this needs to be at least 18 to see the problem.
>}

--
Peter Jeremy

[sage-devel] Re: doctest failures due to rounding errors on Solaris.

Assuring the correctness of the binary-to-decimal conversion of the
sage output routines can and should be done separately from testing
the exp() function.
That should be fairly obvious.

I am amazed by your insistence that this kind of decimal output should
be used in regression testing.
Certainly you can't be saying that your idea of regression testing is
for a human to compare two printed outputs, or even two outputs on a
screen!

So why not have the computer compare the ascii strings of digits on
output? Here's why:

In 2.718 .... 0451, the last "1" adds no information for a double-
float, and so a careful printing program that prints
the minimum number of digits necessary to reconstitute the number
could omit it.

Would that make one of the two equivalent "numbers" erroneous?

RJF


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

William Stein wrote:
> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly <daly@axiom-developer.org> wrote:
>
>> Dr. David Kirkby wrote:
>>
>>> rjf wrote:
>>>
>>>
>>>> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>>> RJF
>>>>>>
>>>>>>
>>>>> The point you are missing is that we want to compare the output what Sage prints
>>>>> to a human.
>>>>>
>>>>>
>>>>>
>>>> The point you are missing is that the following item, which presumably
>>>> could be printed by Sage,
>>>> is perfectly readable to a human:
>>>>
>>>> 6121026514868073 * 2^(-51).
>>>>
>>>> It exactly dictates the bits in an IEEE double-float, and does not
>>>> require any conversion from binary
>>>> to decimal. It does not need rounding. This kind of representation
>>>> does not have any hidden unprinted digits. It does not ever need to
>>>> be longer because of delicate edge conditions of certain numbers.
>>>>
>>>> It happens to evaluate to
>>>> APPROXIMATELY 2.718281828459045
>>>>
>>>>
>>> Sure, Sage could print that. It would also be worth printing the sign bit, so we
>>> could verify the values of
>>>
>>> 1) Sign bit
>>> 2) Significand
>>> 3) Exponent.
>>>
>>> All of those could be correct. But there is still the software which does the
>>> non-trivial task of converting that into the base 10 representation used by
>>> humans. Then in additon to that, there is the software which takes a base 10
>>> number, shows it with the Sage prompt, adding carriage returns etc where
>>> necessary. All of these can go wrong.
>>>
>>> I would think in an almost ideal world, the test would be done at a higher
>>> level, using hardware/software which checked what the monitor actually
>>> displayed. That's not quite as easy to do though.
>>>
>>> Even better would be some way to scan the brain of the user to see what he/she
>>> believes Sage is showing. Perhaps we use a font that is not very good, so
>>> despite being displayed properly, it misunderstood.
>>>
>>> Given most of time people want to see a base 10 representation of a number, and
>>> not a base 2, base 16 or IEE 754 representation, I believe most testing should
>>> be done at the base 10 level.
>>>
>>> If there is a reason for testing the IEEE 754 representation as first choice,
>>> then you have yet to convince me of it.
>>>
>>>
>>> Dave
>>>
>>>
>>>
>>>
>> Dave,
>>
>> Axiom has the same issues.
>>
>> My take on this is that what you check depends on the reason you are
>> checking.
>> If you are generating the output for human use (e.g. a table) then you
>> want decimal.
>> If you are generating the output for regression testing (e.g. checking
>> the answers on
>> multiple hardware) then you probably want Fateman's solution.
>>
>> Tim
>>
>
> The output is used both for human use and for regression testing. Its
> primary use is human -- it's an example in the Sage reference manual:
>
> sage: float(e)
> 2.7182818284590451
>
> This is something a user will look at when reading the documentation
> for some function. It illustrates what happens when they convert the
> symbolic constant e to float.
>
> William
>
>
And therein lies the problem. We use a regression that does a comparison
of the
printed representation of the output of the run with a stored copy of
the output.

All of our regression tests were passing until I installed another,
unrelated program.
Suddenly about 30 regression tests started failing. It turns out that
the unrelated
program upgraded one of the system libraries. The net effect of that
change was
to cause the last digit in the output to "wobble" so that some of the
table values
differ in the nth place (20th, 30th, or thereabouts digit). This caused
the regression
comparisons to fail.

Common lisp will give you the exact bit pattern of the float and this value
does not wobble so the text comparison succeeds with both the old and
the new libraries against the bit pattern.

So I can tell you from experience that what you would like to do is not
going to succeed.

Our solution to the human vs regression problem is to include the stable
bit values in the actual compare and keep the human values in a latex
table. This is easy to do with literate input.

Tim

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly <daly@axiom-developer.org> wrote:
> Dr. David Kirkby wrote:
>> rjf wrote:
>>
>>> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
>>> wrote:
>>>
>>>
>>>>> RJF
>>>>>
>>>> The point you are missing is that we want to compare the output what Sage prints
>>>> to a human.
>>>>
>>>>
>>> The point you are missing is that the following item, which presumably
>>> could be printed by Sage,
>>> is perfectly readable to a human:
>>>
>>> 6121026514868073 * 2^(-51).
>>>
>>> It exactly dictates the bits in an IEEE double-float, and does not
>>> require any conversion from binary
>>> to decimal. It does not need rounding.  This kind of representation
>>> does not have any hidden unprinted digits.  It does not ever need to
>>> be longer because of delicate edge conditions of certain numbers.
>>>
>>> It happens to evaluate to
>>> APPROXIMATELY   2.718281828459045
>>>
>>
>> Sure, Sage could print that. It would also be worth printing the sign bit, so we
>> could verify the values of
>>
>> 1) Sign bit
>> 2) Significand
>> 3) Exponent.
>>
>> All of those could be correct. But there is still the software which does the
>> non-trivial task of converting that into the base 10 representation used by
>> humans. Then in additon to that, there is the software which takes a base 10
>> number, shows it with the Sage prompt, adding carriage returns etc where
>> necessary. All of these can go wrong.
>>
>> I would think in an almost ideal world, the test would be done at a higher
>> level, using hardware/software which checked what the monitor actually
>> displayed. That's not quite as easy to do though.
>>
>> Even better would be some way to scan the brain of the user to see what he/she
>> believes Sage is showing. Perhaps we use a font that is not very good, so
>> despite being displayed properly, it misunderstood.
>>
>> Given most of time people want to see a base 10 representation of a number, and
>> not a base 2, base 16 or IEE 754 representation, I believe most testing should
>> be done at the base 10 level.
>>
>> If there is a reason for testing the IEEE 754 representation as first choice,
>> then you have yet to convince me of it.
>>
>>
>> Dave
>>
>>
>>
> Dave,
>
> Axiom has the same issues.
>
> My take on this is that what you check depends on the reason you are
> checking.
> If you are generating the output for human use (e.g. a table) then you
> want decimal.
> If you are generating the output for regression testing (e.g. checking
> the answers on
> multiple hardware) then you probably want Fateman's solution.
>
> Tim

The output is used both for human use and for regression testing. Its
primary use is human -- it's an example in the Sage reference manual:

sage: float(e)
2.7182818284590451

This is something a user will look at when reading the documentation
for some function. It illustrates what happens when they convert the
symbolic constant e to float.

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

Dr. David Kirkby wrote:
> rjf wrote:
>
>> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
>> wrote:
>>
>>
>>>> RJF
>>>>
>>> The point you are missing is that we want to compare the output what Sage prints
>>> to a human.
>>>
>>>
>> The point you are missing is that the following item, which presumably
>> could be printed by Sage,
>> is perfectly readable to a human:
>>
>> 6121026514868073 * 2^(-51).
>>
>> It exactly dictates the bits in an IEEE double-float, and does not
>> require any conversion from binary
>> to decimal. It does not need rounding. This kind of representation
>> does not have any hidden unprinted digits. It does not ever need to
>> be longer because of delicate edge conditions of certain numbers.
>>
>> It happens to evaluate to
>> APPROXIMATELY 2.718281828459045
>>
>
> Sure, Sage could print that. It would also be worth printing the sign bit, so we
> could verify the values of
>
> 1) Sign bit
> 2) Significand
> 3) Exponent.
>
> All of those could be correct. But there is still the software which does the
> non-trivial task of converting that into the base 10 representation used by
> humans. Then in additon to that, there is the software which takes a base 10
> number, shows it with the Sage prompt, adding carriage returns etc where
> necessary. All of these can go wrong.
>
> I would think in an almost ideal world, the test would be done at a higher
> level, using hardware/software which checked what the monitor actually
> displayed. That's not quite as easy to do though.
>
> Even better would be some way to scan the brain of the user to see what he/she
> believes Sage is showing. Perhaps we use a font that is not very good, so
> despite being displayed properly, it misunderstood.
>
> Given most of time people want to see a base 10 representation of a number, and
> not a base 2, base 16 or IEE 754 representation, I believe most testing should
> be done at the base 10 level.
>
> If there is a reason for testing the IEEE 754 representation as first choice,
> then you have yet to convince me of it.
>
>
> Dave
>
>
>
Dave,

Axiom has the same issues.

My take on this is that what you check depends on the reason you are
checking.
If you are generating the output for human use (e.g. a table) then you
want decimal.
If you are generating the output for regression testing (e.g. checking
the answers on
multiple hardware) then you probably want Fateman's solution.

Tim


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

rjf wrote:
>
> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
> wrote:
>
>>> RJF
>> The point you are missing is that we want to compare the output what Sage prints
>> to a human.
>>
>
> The point you are missing is that the following item, which presumably
> could be printed by Sage,
> is perfectly readable to a human:
>
> 6121026514868073 * 2^(-51).
>
> It exactly dictates the bits in an IEEE double-float, and does not
> require any conversion from binary
> to decimal. It does not need rounding. This kind of representation
> does not have any hidden unprinted digits. It does not ever need to
> be longer because of delicate edge conditions of certain numbers.
>
> It happens to evaluate to
> APPROXIMATELY 2.718281828459045

Sure, Sage could print that. It would also be worth printing the sign bit, so we
could verify the values of

1) Sign bit
2) Significand
3) Exponent.

All of those could be correct. But there is still the software which does the
non-trivial task of converting that into the base 10 representation used by
humans. Then in additon to that, there is the software which takes a base 10
number, shows it with the Sage prompt, adding carriage returns etc where
necessary. All of these can go wrong.

I would think in an almost ideal world, the test would be done at a higher
level, using hardware/software which checked what the monitor actually
displayed. That's not quite as easy to do though.

Even better would be some way to scan the brain of the user to see what he/she
believes Sage is showing. Perhaps we use a font that is not very good, so
despite being displayed properly, it misunderstood.

Given most of time people want to see a base 10 representation of a number, and
not a base 2, base 16 or IEE 754 representation, I believe most testing should
be done at the base 10 level.

If there is a reason for testing the IEEE 754 representation as first choice,
then you have yet to convince me of it.


Dave


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: bug in sagenb - deleting and stopping worksheet does not work

On 31 pro 2009, 09:22, "ma...@mendelu.cz" <ma...@mendelu.cz> wrote:
>
> Does not help either.

Does not help even if I use the install script in sagenb sources
directory to install changewd version. Any other idea?

Many thanks
Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] sage 4.3 compile error Unknown compiler flag: --incref-local-binop

Hello,

I am trying to compile Sage 4.3 (using ./sage -upgrade) and I get the
following error:

...
python `which cython` --embed-positions --incref-local-binop -I/home/
rado/sage/devel/sage-main -o sage/libs/linbox/linbox.cpp sage/libs/
linbox/linbox.pyx
Unknown compiler flag: --incref-local-binop

This happens on two different computers (one running Ubuntu 9.04 and
one 9.10)

Any ideas?

Rado

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: doctest failures due to rounding errors on Solaris.

On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

> > RJF
>
> The point you are missing is that we want to compare the output what Sage prints
> to a human.
>

The point you are missing is that the following item, which presumably
could be printed by Sage,
is perfectly readable to a human:

6121026514868073 * 2^(-51).

It exactly dictates the bits in an IEEE double-float, and does not
require any conversion from binary
to decimal. It does not need rounding. This kind of representation
does not have any hidden unprinted digits. It does not ever need to
be longer because of delicate edge conditions of certain numbers.

It happens to evaluate to
APPROXIMATELY 2.718281828459045

a more accurate rendition of that same number, again in decimal is
2.7182818284590450907955982984....


although a more accurate rendition of exp(1) looks like this.
2.7182818284590452353602874713....

If you want to compare the results of 2 numerical computations for
exact identical bits, then I suggest you
look at the bits.

The fact that two different systems get slightly different answers is
not necessarily an indication of an error.

RJF

> Comparing the bits of a floating point number would not help as a test suite. If
> two systems have the same 64 bits to indicate the number, a bug in the code
> which converts that to ASCII would not be detected. The tests compare ASCII
> text, not numbers.
>
> I would accept for some randomised testing, it might be better to bypaass the
> binary to ASCII conversion, as it would allow for more tests to be conducted in
> less time. But not in general would that be a good idea.
>
> It's 20+ years since I done any assembly language programming - that was on an
> 386/387 chip, then later on a VAX - never SPARC. So I'd be at a loss really.
> (BTW, after programming on a VAX, you realise how limited the x86 series was).
>
> Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

On Wed, Dec 30, 2009 at 10:38 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> Em, This is very odd.  exp(1) gives a different result on SPARC if you build
> with gcc or Sun Studio. GCC is correct, and Sun Studio is wrong. Yet Sage on
> 't2' was build with gcc, not Sun Studio.

gcc is actually inlining exp(1.0) to its correct value. The exp() from
the sun library is incorrect. Try this program instead:

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
double x = 1.0;
if (argc>1)
x = atof(argv[1]);
printf("%.16lf\n",exp(x));
}

Best, Gonzalo

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

rjf wrote:
> You guys could eliminate one (I suspect major) source of confusion by
> not printing the numbers in decimal and reading them back in from
> character strings.
>
> You can read/write exact hexadecimal 64-bit floating-point binary
> numbers.
> or you can write them out as <sign>X <exact integer, written in any
> base you choose> X 2^<exact integer>
> without any error or possible confusion.
>
> There are few people who will claim their numerical library functions
> provide correctly rounded
> results always. Read about the "table-maker's dilemma".
> http://en.wikipedia.org/wiki/Rounding#The_table-maker.27s_dilemma
>
> The fact that rounding of + and * is done right is irrelevant.
> The fact that some computers are doing 80-bit intermediate
> calculations vs 64-bit might be relevant.
> But then if you want them all to agree, you can knee-cap the 80-bit
> machines, so they will be the
> same as 64-bit. Java originally required that.
>
> Instead of flailing around switching Solaris compilers and what-have-
> you
> why not try figuring out whether the bug is printing or computing, or
> even a bug at all.
>
> RJF

The point you are missing is that we want to compare the output what Sage prints
to a human.

Comparing the bits of a floating point number would not help as a test suite. If
two systems have the same 64 bits to indicate the number, a bug in the code
which converts that to ASCII would not be detected. The tests compare ASCII
text, not numbers.

I would accept for some randomised testing, it might be better to bypaass the
binary to ASCII conversion, as it would allow for more tests to be conducted in
less time. But not in general would that be a good idea.

It's 20+ years since I done any assembly language programming - that was on an
386/387 chip, then later on a VAX - never SPARC. So I'd be at a loss really.
(BTW, after programming on a VAX, you realise how limited the x86 series was).

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: doctest failures due to rounding errors on Solaris.

You guys could eliminate one (I suspect major) source of confusion by
not printing the numbers in decimal and reading them back in from
character strings.

You can read/write exact hexadecimal 64-bit floating-point binary
numbers.
or you can write them out as <sign>X <exact integer, written in any
base you choose> X 2^<exact integer>
without any error or possible confusion.

There are few people who will claim their numerical library functions
provide correctly rounded
results always. Read about the "table-maker's dilemma".
http://en.wikipedia.org/wiki/Rounding#The_table-maker.27s_dilemma

The fact that rounding of + and * is done right is irrelevant.
The fact that some computers are doing 80-bit intermediate
calculations vs 64-bit might be relevant.
But then if you want them all to agree, you can knee-cap the 80-bit
machines, so they will be the
same as 64-bit. Java originally required that.

Instead of flailing around switching Solaris compilers and what-have-
you
why not try figuring out whether the bug is printing or computing, or
even a bug at all.

RJF

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

Robert Bradshaw wrote:
> On Dec 30, 2009, at 4:38 PM, Dr. David Kirkby wrote:
>
>> Robert Bradshaw wrote:
>>>>>>> **********************************************************************
>>>>>>> File "/rootpool2/local/kirkby/sage-4.3/devel/sage/sage/symbolic/
>>>>>>> pynac.pyx", line
>>>>>>> 1276:
>>>>>>> sage: py_exp(float(1))
>>>>>>> Expected:
>>>>>>> 2.7182818284590451
>>>>>>> Got:
>>>>>>> 2.7182818284590455
>>> Yes, that could be the difference for exp. What's more worrisome is
>>> that the C compiler incorrectly resolves the literal floating point
>>> 2.7182818284590452354 .
>>>
>>> - Robert
>>>
>> Em, This is very odd. exp(1) gives a different result on SPARC if
>> you build
>> with gcc or Sun Studio. GCC is correct, and Sun Studio is wrong. Yet
>> Sage on
>> 't2' was build with gcc, not Sun Studio.
>
> I was actually unable to start sage on t2, so my experience is just
> with the plain system Python. (Do you know what that was built with?)

There's a semi-stable release of Sage at:

/rootpool2/local/kirkby/sage-4.3
)

I call it semi-stable, as I do occasionally make changes that might break it
temporarily, but I always put it back to a working Sage.

However, there is also

http://t2nb.math.washington.edu:8000/

which has Sage 4.3. That is a Solaris zone on the host t2.

If you want your own copy on 't2' which you can recompile easily, I could give
you one. I have a tar file on the zone 't2nb' which has both the source and
binaries of a complete stable version. I could copy that somewhere and make it
available if you want. (It's the tarball I used to copy Sage into the zone).

>> IMHO, this should not be covered up by reducing the number of digits
>> compared,
>> but recorded as a failure. Many packages have 'expected failures'.
>> It would be
>> better if this was recorded as an 'expected failure'. I appreciate
>> that might
>> not be how the doctests work now.
>
> Given the above, and the fact that we're looking at exp(1) and math.e,
> I'm also starting to lean towards the fact that this should be correct
> on every system, and we've uncovered a bug of some sort.
>
> - Robert

What I find odd is the fact that gcc gets it right with my noddy C program. But
when that gcc is used to build Sage, we find that Sage gets the same answer as
Sun Studio. One might suggest a different library might be used, but both gcc
and Sun Studio link against the same 3 libraries.

irkby@t2:[~] $ /opt/SUNWspro/bin/cc -lm exp.c
kirkby@t2:[~] $ ldd a.out
libm.so.2 => /lib/libm.so.2
libc.so.1 => /lib/libc.so.1
/platform/SUNW,T5240/lib/libc_psr.so.1
kirkby@t2:[~] $ gcc exp.c
kirkby@t2:[~] $ ldd a.out
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,T5240/lib/libc_psr.so.1
kirkby@t2:[~] $

I do not know if there is any significance in the fact that ldd shows libm
before libc when built with the Sun compiler but swaps them when built with gcc.

There's no implementation of 'exp' in libc, as the following shows.

kirkby@t2:[~] $ /opt/SUNWspro/bin/cc exp.c
Undefined first referenced
symbol in file
exp exp.o
ld: fatal: Symbol referencing errors. No output written to a.out

I'm certainly against coving this up just now at least.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

On Dec 30, 2009, at 4:38 PM, Dr. David Kirkby wrote:

> Robert Bradshaw wrote:
>>>>
>>>>>> **********************************************************************
>>>>>> File "/rootpool2/local/kirkby/sage-4.3/devel/sage/sage/symbolic/
>>>>>> pynac.pyx", line
>>>>>> 1276:
>>>>>> sage: py_exp(float(1))
>>>>>> Expected:
>>>>>> 2.7182818284590451
>>>>>> Got:
>>>>>> 2.7182818284590455
>
>> Yes, that could be the difference for exp. What's more worrisome is
>> that the C compiler incorrectly resolves the literal floating point
>> 2.7182818284590452354 .
>>
>> - Robert
>>
>
> Em, This is very odd. exp(1) gives a different result on SPARC if
> you build
> with gcc or Sun Studio. GCC is correct, and Sun Studio is wrong. Yet
> Sage on
> 't2' was build with gcc, not Sun Studio.

I was actually unable to start sage on t2, so my experience is just
with the plain system Python. (Do you know what that was built with?)

> On Open Solaris, using a Xeon processor, the two compilers give the
> same result.
>
> Here's a noddy C program:
>
> drkirkby@kestrel:~$ cat exp.c
> #include <math.h>
> #include <stdio.h>
>
> int main() {
> printf("%.16lf\n",exp(1.0));
> }
>
> This data below is from a SPARC (sun4u architecture) of mine. I've
> tried on 't2'
> (sun4v) and get exactly the same results.
>
> drkirkby@kestrel:~$ uname -a
> SunOS kestrel 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2
> drkirkby@kestrel:~$ cat exp.c
> #include <math.h>
> #include <stdio.h>
>
> int main() {
> printf("%.16lf\n",exp(1.0));
> }
>
> drkirkby@kestrel:~$ gcc exp.c
> drkirkby@kestrel:~$ ./a.out
> 2.7182818284590451
> drkirkby@kestrel:~$ /opt/sunstudio12.1/bin/cc -lm exp.c
> drkirkby@kestrel:~$ ./a.out
> 2.7182818284590455
>
> Now, when I do this on Open Solaris, I get the same result with each
> compiler.
>
> bash-3.2$ uname -a
> SunOS hawk 5.11 snv_111b i86pc i386 i86pc
> bash-3.2$ gcc exp.c
> bash-3.2$ ./a.out
> 2.7182818284590451
> bash-3.2$ /opt/sunstudio12.1/bin/cc -lm exp.c
> bash-3.2$ ./a.out
> 2.7182818284590451
>
> I also tried this on HP-UX, and get the same (correct) result with
> both the
> native HP compiler and with gcc.
>
> -bash-4.0$ uname -a
> HP-UX hpbox B.11.11 U 9000/785 2016698240 unlimited-user license
> -bash-4.0$ gcc exp.c
> -bash-4.0$ ./a.out
> 2.7182818284590451
> -bash-4.0$ cc -lm exp.c
> -bash-4.0$ ./a.out
> 2.7182818284590451
>
> IMHO, this should not be covered up by reducing the number of digits
> compared,
> but recorded as a failure. Many packages have 'expected failures'.
> It would be
> better if this was recorded as an 'expected failure'. I appreciate
> that might
> not be how the doctests work now.

Given the above, and the fact that we're looking at exp(1) and math.e,
I'm also starting to lean towards the fact that this should be correct
on every system, and we've uncovered a bug of some sort.

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: bug in sagenb - deleting and stopping worksheet does not work

THnks for your suggestions,

On 31 pro, 04:26, Pat LeSmithe <qed...@gmail.com> wrote:
> On 12/30/2009 01:31 PM, ma...@mendelu.cz wrote:
>
> > I did more tests - Sage 4.2. is the last version where deleting and
> > stopping workseehts via buttons from "Home" folder works for me.
>
> One or more of these problems may appear in many other browsers, too.
> Could you try commenting out
>
>         if not self.worksheet.is_published():
>             self.worksheet.set_active(username)
>
> in
>
> SAGE_LOCAL/lib/python2.6/site-packages/sagenb-*/sagenb/notebook/twist.py
>
> and testing again in Firefox, say?  (See WorksheetResource.__init__,
> around line 516.)

I did this change, run sage -b and then sage, but still have old
behavior.

>
> A worksheet opened in a JavaScript-enabled tab or window pings the
> server every ~10 seconds.  The lines above reset the worksheet's "view"
> to ACTIVE for the user who opened the worksheet.  The worksheet will
> then appear in that user's [refreshed] list of active worksheets.
>
> Another possible workaround is to close all tabs/windows with the
> worksheet in question, before sending it to the Trash folder.

Does not help either.
And I do not understand why I have this issue on 4 different computers
and nobody else reported such a problem ....

Anyway, thank you for your help and have a nice happy new year :)

Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันพุธที่ 30 ธันวาคม พ.ศ. 2552

[sage-devel] Re: Seeing the effect of the method text in the given variable

Sami Losoi wrote:
> *How is the effect of the method text stored in the given variable?*
>
> Example of the situation:
>
> sage: p = plot(x**2,x) + text("hello", (1,2))
> sage: dir(p)
> ['SHOW_OPTIONS', ' - - cut - -
>
> The last command suggests that the effect of the method text is stored
> in one of the variables in the list. It is not stored in plain text,
> since a simple regex does not match "text".
>
> The question is related to the ticket at
> http://trac.sagemath.org/sage_trac/ticket/7798


I'm confused about what exactly you are trying to do with that ticket.
What precisely do you want? Are you trying to label the curves with
labels? Would a legend be sufficent? That is what is implemented in
http://trac.sagemath.org/sage_trac/ticket/4342, which apparently never
was finished/reviewed/merged.

Thanks,

Jason

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: bug in sagenb - deleting and stopping worksheet does not work

On 12/30/2009 01:31 PM, marik@mendelu.cz wrote:
> I did more tests - Sage 4.2. is the last version where deleting and
> stopping workseehts via buttons from "Home" folder works for me.

One or more of these problems may appear in many other browsers, too.
Could you try commenting out

if not self.worksheet.is_published():
self.worksheet.set_active(username)

in

SAGE_LOCAL/lib/python2.6/site-packages/sagenb-*/sagenb/notebook/twist.py

and testing again in Firefox, say? (See WorksheetResource.__init__,
around line 516.)

A worksheet opened in a JavaScript-enabled tab or window pings the
server every ~10 seconds. The lines above reset the worksheet's "view"
to ACTIVE for the user who opened the worksheet. The worksheet will
then appear in that user's [refreshed] list of active worksheets.

Another possible workaround is to close all tabs/windows with the
worksheet in question, before sending it to the Trash folder.

I think the current ACTIVE, ARCHIVE, and TRASH views are just a first
take on a system for tagging (labeling) worksheets. I don't know how it
will develop. Perhaps we'll add columns, slices, etc.?

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Seeing the effect of the method text in the given variable

How is the effect of the method text stored in the given variable?

Example of the situation:

sage: p = plot(x**2,x) + text("hello", (1,2))
sage: dir(p)
['SHOW_OPTIONS', ' - - cut - -

The last command suggests that the effect of the method text is stored in one of the variables in the list. It is not stored in plain text, since a simple regex does not match "text".

The question is related to the ticket at http://trac.sagemath.org/sage_trac/ticket/7798

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Should sage-env print variables it uses?

William Stein wrote:

> I realized that the issue is that it would print all the variables out
> when I type
>
> $ sage
> ... many variables
> ...
> sage:
>
> Which many would find annoying.
>
> You could make an environment variable though that makes it print out
> those vars. E.g., SAGE_PORT or SAGE_DEBUG or SAGE_KIRKBY or
> something. That would be fine for me.
>
> William

Yes.

I think they would be useful to record in the install.log. I don't know if there
would be a way of printing them once at the start of the build, but not when
Sage is actually run. I can see that would be very annoying, even if used with
SAGE_DEBUG or SAGE_PORT. It would need something quite unique, though I'm not
sure I like SAGE_KIRKBY! I'll think of something.

dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Should sage-env print variables it uses?

On Wed, Dec 30, 2009 at 5:34 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> William Stein wrote:
>> On Wed, Dec 30, 2009 at 5:10 PM, Dr. David Kirkby
>> <david.kirkby@onetel.net> wrote:
>>> At the bottom of sage-env, there is some code which can obviously be changed to
>>> print the value of some variables, but currently does not do so.
>>>
>>> if [ 1 = 2 ]; then
>>> echo "AR=$AR"
>>> echo "AS=$AS"
>>> echo "CC=$CC"
>>> echo "CFLAGS=$CFLAGS"
>>> echo "CXX=$CXX"
>>> echo "CXXFLAGS=$CXXFLAGS"
>>> echo "ECLDIR=$ECLDIR"
>>> echo "LD=$LD"
>>> echo "LDFLAGS=$LDFLAGS"
>>> echo "LN=$LN"
>>> echo "MAKE=$MAKE"
>>> echo "MAKEFLAGS=$MAKEFLAGS (MFLAGS will be exported the same too)"
>>> echo "RANLIB=$RANLIB"
>>> echo "SAGE64=$SAGE64"
>>> echo "SHAREDFLAGS=$SHAREDFLAGS"
>>> echo "If any of the above are wrong, or are not optimal, override"
>>> echo "them by setting the appropiate enviroment variable."
>>> fi
>>>
>>>
>>> Would it not be more sensible to print these? I wanted to add to this list some
>>> other variables, and it would be useful to have a record of what they are set to.
>>>
>>>
>>
>> You wrote that code when you wrote sage-env in 2005.  It drove me
>> crazy.   So I disabled it.
>>
>> If you add it again, it'll again drive me crazy.
>>
>> William
>
>
> OK, I wont drive you crazy!

:-)

I realized that the issue is that it would print all the variables out
when I type

$ sage
... many variables
...
sage:

Which many would find annoying.

You could make an environment variable though that makes it print out
those vars. E.g., SAGE_PORT or SAGE_DEBUG or SAGE_KIRKBY or
something. That would be fine for me.

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Should sage-env print variables it uses?

William Stein wrote:
> On Wed, Dec 30, 2009 at 5:10 PM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> At the bottom of sage-env, there is some code which can obviously be changed to
>> print the value of some variables, but currently does not do so.
>>
>> if [ 1 = 2 ]; then
>> echo "AR=$AR"
>> echo "AS=$AS"
>> echo "CC=$CC"
>> echo "CFLAGS=$CFLAGS"
>> echo "CXX=$CXX"
>> echo "CXXFLAGS=$CXXFLAGS"
>> echo "ECLDIR=$ECLDIR"
>> echo "LD=$LD"
>> echo "LDFLAGS=$LDFLAGS"
>> echo "LN=$LN"
>> echo "MAKE=$MAKE"
>> echo "MAKEFLAGS=$MAKEFLAGS (MFLAGS will be exported the same too)"
>> echo "RANLIB=$RANLIB"
>> echo "SAGE64=$SAGE64"
>> echo "SHAREDFLAGS=$SHAREDFLAGS"
>> echo "If any of the above are wrong, or are not optimal, override"
>> echo "them by setting the appropiate enviroment variable."
>> fi
>>
>>
>> Would it not be more sensible to print these? I wanted to add to this list some
>> other variables, and it would be useful to have a record of what they are set to.
>>
>>
>
> You wrote that code when you wrote sage-env in 2005. It drove me
> crazy. So I disabled it.
>
> If you add it again, it'll again drive me crazy.
>
> William


OK, I wont drive you crazy!

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Should sage-env print variables it uses?

On Wed, Dec 30, 2009 at 5:10 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> At the bottom of sage-env, there is some code which can obviously be changed to
> print the value of some variables, but currently does not do so.
>
> if [ 1 = 2 ]; then
> echo "AR=$AR"
> echo "AS=$AS"
> echo "CC=$CC"
> echo "CFLAGS=$CFLAGS"
> echo "CXX=$CXX"
> echo "CXXFLAGS=$CXXFLAGS"
> echo "ECLDIR=$ECLDIR"
> echo "LD=$LD"
> echo "LDFLAGS=$LDFLAGS"
> echo "LN=$LN"
> echo "MAKE=$MAKE"
> echo "MAKEFLAGS=$MAKEFLAGS (MFLAGS will be exported the same too)"
> echo "RANLIB=$RANLIB"
> echo "SAGE64=$SAGE64"
> echo "SHAREDFLAGS=$SHAREDFLAGS"
> echo "If any of the above are wrong, or are not optimal, override"
> echo "them by setting the appropiate enviroment variable."
> fi
>
>
> Would it not be more sensible to print these? I wanted to add to this list some
> other variables, and it would be useful to have a record of what they are set to.
>
>

You wrote that code when you wrote sage-env in 2005. It drove me
crazy. So I disabled it.

If you add it again, it'll again drive me crazy.

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Should sage-env print variables it uses?

At the bottom of sage-env, there is some code which can obviously be changed to
print the value of some variables, but currently does not do so.

if [ 1 = 2 ]; then
echo "AR=$AR"
echo "AS=$AS"
echo "CC=$CC"
echo "CFLAGS=$CFLAGS"
echo "CXX=$CXX"
echo "CXXFLAGS=$CXXFLAGS"
echo "ECLDIR=$ECLDIR"
echo "LD=$LD"
echo "LDFLAGS=$LDFLAGS"
echo "LN=$LN"
echo "MAKE=$MAKE"
echo "MAKEFLAGS=$MAKEFLAGS (MFLAGS will be exported the same too)"
echo "RANLIB=$RANLIB"
echo "SAGE64=$SAGE64"
echo "SHAREDFLAGS=$SHAREDFLAGS"
echo "If any of the above are wrong, or are not optimal, override"
echo "them by setting the appropiate enviroment variable."
fi


Would it not be more sensible to print these? I wanted to add to this list some
other variables, and it would be useful to have a record of what they are set to.


Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

Robert Bradshaw wrote:
>>>
>>>>> **********************************************************************
>>>>> File "/rootpool2/local/kirkby/sage-4.3/devel/sage/sage/symbolic/
>>>>> pynac.pyx", line
>>>>> 1276:
>>>>> sage: py_exp(float(1))
>>>>> Expected:
>>>>> 2.7182818284590451
>>>>> Got:
>>>>> 2.7182818284590455

> Yes, that could be the difference for exp. What's more worrisome is
> that the C compiler incorrectly resolves the literal floating point
> 2.7182818284590452354 .
>
> - Robert
>

Em, This is very odd. exp(1) gives a different result on SPARC if you build
with gcc or Sun Studio. GCC is correct, and Sun Studio is wrong. Yet Sage on
't2' was build with gcc, not Sun Studio.

On Open Solaris, using a Xeon processor, the two compilers give the same result.

Here's a noddy C program:

drkirkby@kestrel:~$ cat exp.c
#include <math.h>
#include <stdio.h>

int main() {
printf("%.16lf\n",exp(1.0));
}

This data below is from a SPARC (sun4u architecture) of mine. I've tried on 't2'
(sun4v) and get exactly the same results.

drkirkby@kestrel:~$ uname -a
SunOS kestrel 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2
drkirkby@kestrel:~$ cat exp.c
#include <math.h>
#include <stdio.h>

int main() {
printf("%.16lf\n",exp(1.0));
}

drkirkby@kestrel:~$ gcc exp.c
drkirkby@kestrel:~$ ./a.out
2.7182818284590451
drkirkby@kestrel:~$ /opt/sunstudio12.1/bin/cc -lm exp.c
drkirkby@kestrel:~$ ./a.out
2.7182818284590455

Now, when I do this on Open Solaris, I get the same result with each compiler.

bash-3.2$ uname -a
SunOS hawk 5.11 snv_111b i86pc i386 i86pc
bash-3.2$ gcc exp.c
bash-3.2$ ./a.out
2.7182818284590451
bash-3.2$ /opt/sunstudio12.1/bin/cc -lm exp.c
bash-3.2$ ./a.out
2.7182818284590451

I also tried this on HP-UX, and get the same (correct) result with both the
native HP compiler and with gcc.

-bash-4.0$ uname -a
HP-UX hpbox B.11.11 U 9000/785 2016698240 unlimited-user license
-bash-4.0$ gcc exp.c
-bash-4.0$ ./a.out
2.7182818284590451
-bash-4.0$ cc -lm exp.c
-bash-4.0$ ./a.out
2.7182818284590451

IMHO, this should not be covered up by reducing the number of digits compared,
but recorded as a failure. Many packages have 'expected failures'. It would be
better if this was recorded as an 'expected failure'. I appreciate that might
not be how the doctests work now.

Dave

PS

It's interesting how both HP and Sun compilers need the '-lm' to link in the
maths library. GCC does that by default.

http://trac.sagemath.org/sage_trac/ticket/7067

is an open ticket which is caused by making the incorrect assumption that the C
compiler will automatically link in the maths library.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Producing patch - no working Sage

Minh Nguyen wrote:
> Hi David,
>
> On Thu, Dec 31, 2009 at 4:54 AM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>
> <SNIP>
>
>> (I normally tend to extract the file, then
>> increment the patch number, so I'd be editing
>> $SAGE_ROOT/spkg/standard/foobar-1.0.p0/spkg-install
>
> That sounds sensible.
>
>
>> Martin Albrecht added a patch for me to
>>
>> http://trac.sagemath.org/sage_trac/ticket/7505
>>
>> which adds two new files
>>
>> $SAGE_ROOT/spkg/base/testcc.sh
>> $SAGE_ROOT/spkg/base/testcxx.sh
>>
>> I noticed the diff is relative to /dev/null That patch needs updating now. I'm
>> not sure the best way to do that.
>
> As you said on ticket #7505, your latest attachments "testcc.sh" and
> "testcxx.sh" are updated versions of previous attachments. I
> understand that Martin's patch "trac_7505.patch" is a patch file for
> your earlier test scripts. Now that you have attached newer versions
> of the test scripts, I think it's not necessary to also update
> Martin's patch. What you can do is create a new patch from your
> updated test scripts. Without using Mercurial, this can be done as
> follows:
>
> [mvngu@t2 trac-7505]$ diff -u /dev/null testcc.sh > testcc.diff
> [mvngu@t2 trac-7505]$ diff -u /dev/null testcxx.sh > testcxx.diff
> [mvngu@t2 trac-7505]$ cat testcc.diff testcxx.diff >
> trac_7505-test-scripts.patch
> [mvngu@t2 trac-7505]$ ls
> testcc.diff testcxx.sh
> testcc.sh trac_7505-test-scripts.patch
> testcxx.diff
>
> So you can now upload "trac_7505-test-scripts.patch" to the trac server.
>
>
>> There's nothing in the patch which would
>> suggest where the files go, though it is explained in the ticket, and the reason
>> why.
>
> I see that you and Martin have agreed to place the test scripts under
>
> SAGE_ROOT/spkg/base

> Martin's patch was probably produced somewhere outside of the Sage
> directory tree. But I think that doesn't matter in this case. To apply
> a patch using "patch" and without using hg, you download the patch
> file to the relevant directory and use the "patch" command. I admit
> that doing something like this

Thank you. I've put the patch on the server. If you have a spare minute, perhaps
you could review it. A few people have looked at it, and Peter Jeremy has made
some significant changes, so he can no longer review it. I'd like to get it into
Sage asap, as then one can develop a better solution to this 64-bit issue with
spkg-install scripts, where some of them only work on OS X, and some work on any
platform.

Once we know what *compiler* someone is using, we can determine what is the
appropriate option to build a 64-bit executable - if any are needed.

I don't know of a linux box which has Sun Studio installed, but if there was
one, the scripts should report 'Sun_Studio'. I'm unable to test on every
platform, but they work on any I have tried.

> patch < trac_7505.patch
>
> is OK under Linux. But on Solaris, I have trouble using "patch" as the
> above command is more chatty. It's a common experience, I think, of
> people like myself who are transitioning to using non-GNU tools on
> Unix.

Yes, there are differences, and they can be annoying some times. That has been
very much the history of Unix in general - many versions all a bit different.

I do not know how accurate this diagram on Wikipedia is:

http://en.wikipedia.org/wiki/File:Unix_history-simple.en.svg

but it gives at least some idea of how influence each other. I've never even
heard of 'OpenServer' until I looked at that diagram, though I know of SCO unix
from which it is derived. I've also used one commerical distribution of Unix,
which is not on that diagram. But I can't even recall what it was called. It was
similar to SCO unix, and run on x86 PCs. It came on 5.25" floppy disks -
probably before your time!

Linux is following that tradition, with many distributions, all a bit different.

http://en.wikipedia.org/wiki/Linux_distribution

says there are over 600 distributions, with over 300 of them maintained. I do
not know how true that is.

But I personally prefer to use just POSIX options, then I can be 99% sure they
will work on any platform. Even systems which are not fully POSIX compliant,
usually support those options.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

On Dec 30, 2009, at 8:49 AM, Dr. David Kirkby wrote:

> Robert Bradshaw wrote:
>> On Dec 29, 2009, at 9:59 PM, Peter Jeremy wrote:
>>
>>> On 2009-Dec-29 23:29:42 +0000, "Dr. David Kirkby" <david.kirkby@onetel.net
>>>> wrote:
>>>> There are a few failures, but these couple just came up, and look
>>>> rather odd, as this is only an error in the last decimal place, and
>>>> so will be subject to rounding errors with different floating point
>>>> processors. They do not really seem failures to me.
>>> One of the claims for IEEE-754 arithmetic is that basic arithmetic
>>> operations (+, -, *, /, sqrt) will give bit-for-bit identical
>>> results on different implementations.
>>
>> I would have expected t2 to be IEEE-754 compliant, but maybe it
>> isn't.
>>
>>>> **********************************************************************
>>>> File "/rootpool2/local/kirkby/sage-4.3/devel/sage/sage/symbolic/
>>>> pynac.pyx", line
>>>> 1276:
>>>> sage: py_exp(float(1))
>>>> Expected:
>>>> 2.7182818284590451
>>>> Got:
>>>> 2.7182818284590455
>>>> **********************************************************************
>>> As a correctly rounded IEEE-754 double precision constant,
>>> e=0x4005BF0A8B145769 (0x2.B7E1 5162 8AED 2), this should convert
>>> to 2.7182818284590451 (rounded to "sufficient" accuracy).
>>>
>>> 2.7182818284590455 is 1ULP high - this may reflect a rounding error
>>> in either the exp() or double_to_ascii() implementation.
>>
>> It's probably not double_to_ascii, as (on t2)
>>
>>>>> float("2.7182818284590452353602874713526625")
>> 2.7182818284590451
>>
>> I bet Solaris has a completely different (and unfortunately not as
>> accurate) implementation of exp in its libm. It could also be a bug
>> in
>> the compiler, as math.e is defined as
>
> I might be mistaken, but I believe the SPARC processor users 64 bits
> for
> floating point and the Intel chips use 80 internally, so it might be
> an issue
> with the processor. I've got no idea how that fits in with IEEE-754.

Yes, that could be the difference for exp. What's more worrisome is
that the C compiler incorrectly resolves the literal floating point
2.7182818284590452354 .

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: licenses for sage-enhanced books to be eventually included in Sage

>
> I never really thought about this distinction--I wish there was  
> something like CC-by-sa-src as well. Source doesn't make as much sense  
> for a photo, but for something like a LaTeX document or a vector  
> graphic it is very valuable--almost an essential part of the "share  
> alike" idea. That's a strong argument for the GFDL. Even then, most  
> stuff doesn't fall into the 100+ pages category, and the GFDL is a lot  
> harder (for me) to be sure I understand (The CC, even the legalese  
> version, is much more readable.), and the GFDL requirements to contain  
> the full license is more draconian. Interesting question--now that  
> wikipedia is CC-by-sa, can I take the full text, make some  
> improvements, and satisfy the license by selling PDFs only? Would  
> certainly seem to violate the spirit of the license.
>
> BTW, I don't think there's any conflict issues with the GPL of any  
> code involved--they don't link to each other.
>
> - Robert

Actually, there is a company that does just that! They take wikipedia
articles and make books.[1] There was a discussion related to a new
Lisp book [2]. They are selling books on Amazon. I love the one that
is supposed to be about Georgia (Eastern Europe) that has a picture of
Atlanta, Georgia, USA on the cover [3]. Quality. ;-)

Cheers,
Adam

[1] http://www.alphascript-publishing.com/index.php?&act=nav&nav=10048
[2] http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/784e2ad8f734fb8b/cda6809c45c123a7?#cda6809c45c123a7
[3] http://www.amazon.com/History-Georgia-country-Democratic-Tao-Klarjeti/dp/6130007442/ref=cm_cr-mr-title

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: bug in sagenb - deleting and stopping worksheet does not work

I did more tests - Sage 4.2. is the last version where deleting and
stopping workseehts via buttons from "Home" folder works for me.


Tested on some personal installations as well as at https://sagenb.kaist.ac.kr
(4.2.1 - does not work) http://uw.sagenb.org (4.2.1 - does not work)
and http://www.sagenb.org/ (4.3 - does not work). Tested on various
local OS (windows, several Linux installations) and various browsers
(Firefox, Opera, K-Meleon).

Is there anybody else here, who can either confirm this problem or
anybody else who does not have any problems of this type?

I started courses at January 4 wihch will use Sage and this is
annoying. On the other had, it would be nice to work with version with
fixed http://trac.sagemath.org/sage_trac/ticket/7756

Many thanks

Robert Marik

On 28 pro, 11:03, "ma...@mendelu.cz" <ma...@mendelu.cz> wrote:
> On 28 pro, 07:39, Pat LeSmithe <qed...@gmail.com> wrote:
>
>
>
> > Which versions of Firefox and Sage?
>
> Tested on Windows Vista (Firefox 3.0.16, K-meleon, Opera) and Debian
> (Epiphany) on two servers with Sage 4.3 (sagenb.org and sage server at
> Mendel university - sage compiled from sources)
>
> The buttons Archive,Deleteand Stop do no work. Can someone else
> reproduce the problem or confirm that tese buttons work for her/him?
>
> Many thanks
> Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Fwd: SAGE ignores Ctrl-C?!? Is this a bug or a feature

On 30 Dez., 21:09, Simon King <simon.k...@nuigalway.ie> wrote:
> Third (and probably most debatable) reason:
> If we forget the monomial order for a moment: How does a polynomial
> ring in x over a polynomial ring in y differ from a polynomial ring in
> x and y, computationally? Shouldn't one simplify a construction if the
> result is computationally equivalent?

I meant to write: Shouldn't one *automatically* simplify a
construction? Of course, this is only possible if the result of the
simplified construction is computationally equivalent to the result of
the unsimplified construction -- which (I think) is essentially the
case here.

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Fwd: SAGE ignores Ctrl-C?!? Is this a bug or a feature

Hi John!

On 30 Dez., 18:18, John Cremona <john.crem...@gmail.com> wrote:
[...]
> As it is defined, PP is a polynomial ring in one variable over a
> polynomial ring in one variable.
> Would it be a good thing to  automatically convert this into a
> polynomial ring with *two* variables? What do people think?
>
> I think: no, I do not want this automatic conversion and I can think
> of situations where it is a bad idea.

It should be somehow restrictive, for example with respect to monomial
order. This is something I spent a lot of work on in my patch at
http://trac.sagemath.org/sage_trac/ticket/7580: If P is a ring and one
constructs a (finite or infinite) polynomial ring R over P then P
should be an *ordered* subring of R.

However, I think that a more sensible than the present mechanism is
necessary, for at least two reasons.

The first:
sage: R.<t>=ZZ['t'][]
sage: R
Univariate Polynomial Ring in t over Univariate Polynomial Ring in
t over Integer Ring

So, sage swallows a ring definition with two conflicting meanings of
t. I think in such situations an error should be raised -- and in the
patch for #7580 I demonstrate how this can be done, even if one has
R=ZZ['t']['x']['t'] (hence, the first t is not a variable in the
basering of R, but is a variable in the basering of the basering of
R).

Second reason:
Subsequent computations will be much quicker (and, by my experience,
less buggy) if one works in MPolynomialRing_libsingular, rather than
relying on generic algorithms in MPolynomialRing_polydict or
MPolynomialRing_integral_domain. So, it does make sense to keep the
definition simple.

Third (and probably most debatable) reason:
If we forget the monomial order for a moment: How does a polynomial
ring in x over a polynomial ring in y differ from a polynomial ring in
x and y, computationally? Shouldn't one simplify a construction if the
result is computationally equivalent?

And a last argument, more an observation:
From the point of view of construction functors, what I suggest is
already done in Sage.
sage: Fy,Fx = QQ['x','y'].construction()[0].expand()
sage: Fy
MPoly[y]
sage: Fx
MPoly[x]
sage: (Fy*Fx)(QQ)
Multivariate Polynomial Ring in x, y over Rational Field

Unfortunately, the construction functors are not functorial:
sage: Fy(Fx(QQ))
Univariate Polynomial Ring in y over Univariate Polynomial Ring in x
over Rational Field

So, (Fy*Fx)(QQ) != Fy(Fx(QQ)). Not nice. On the one hand, (Fy*Fx)
does what I suggests, on the other hand, Fy(Fx()) doesn't.

Best regards,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: conjugates in SR disappear

> The first comment on the ticket by Karl-Dieter shows a workaround:

Thank you!

/Håkan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] conjugates in SR disappear

On Wed, 30 Dec 2009 10:56:42 -0800 (PST)
Håkan Granath <hakan.granath@googlemail.com> wrote:

> When using conjugate() in the symbolic ring some functions seem to
> forget the conjugate:
>
> ----------------------------------------------------------------------
> | Sage Version 4.3, Release Date: 2009-12-24 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> sage: var('z')
> z
> sage: m=z*z.conjugate()
> sage: m
> z*conjugate(z)
> sage: m.factor()
> z^2
> sage: m.simplify()
> z^2

The factor() and simplify() functions call maxima, which by default
assumes the variables are real. This is already in trac as #6862:

http://trac.sagemath.org/sage_trac/ticket/6862

The first comment on the ticket by Karl-Dieter shows a workaround:

sage: var('z')
z
sage: assume(z, 'complex')
sage: t = z*conjugate(z); t
z*conjugate(z)
sage: t.factor()
z*conjugate(z)
sage: t.simplify()
z*conjugate(z)


Happy new year!

Cheers,
Burcin

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-check-64

Hi David,

On Thu, Dec 31, 2009 at 5:16 AM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:

<SNIP>

> Where does that file come from? It seems to magically appear in local/bin if one
> builds Sage, but I've no idea where it is stored, and so what needs editing.

The file sage-check-64 is usually packed in the spkg
sage_scripts-x.y.z.spkg, which is a standard package under
SAGE_ROOT/spkg/standard. During the build process, many scripts in
that package are copied over to SAGE_ROOT/local/bin.

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Producing patch - no working Sage

Hi David,

On Thu, Dec 31, 2009 at 4:54 AM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:

<SNIP>

> (I normally tend to extract the file, then
> increment the patch number, so I'd be editing
> $SAGE_ROOT/spkg/standard/foobar-1.0.p0/spkg-install

That sounds sensible.


> Martin Albrecht added a patch for me to
>
> http://trac.sagemath.org/sage_trac/ticket/7505
>
> which adds two new files
>
> $SAGE_ROOT/spkg/base/testcc.sh
> $SAGE_ROOT/spkg/base/testcxx.sh
>
> I noticed the diff is relative to /dev/null That patch needs updating now. I'm
> not sure the best way to do that.

As you said on ticket #7505, your latest attachments "testcc.sh" and
"testcxx.sh" are updated versions of previous attachments. I
understand that Martin's patch "trac_7505.patch" is a patch file for
your earlier test scripts. Now that you have attached newer versions
of the test scripts, I think it's not necessary to also update
Martin's patch. What you can do is create a new patch from your
updated test scripts. Without using Mercurial, this can be done as
follows:

[mvngu@t2 trac-7505]$ diff -u /dev/null testcc.sh > testcc.diff
[mvngu@t2 trac-7505]$ diff -u /dev/null testcxx.sh > testcxx.diff
[mvngu@t2 trac-7505]$ cat testcc.diff testcxx.diff >
trac_7505-test-scripts.patch
[mvngu@t2 trac-7505]$ ls
testcc.diff testcxx.sh
testcc.sh trac_7505-test-scripts.patch
testcxx.diff

So you can now upload "trac_7505-test-scripts.patch" to the trac server.


> There's nothing in the patch which would
> suggest where the files go, though it is explained in the ticket, and the reason
> why.

I see that you and Martin have agreed to place the test scripts under

SAGE_ROOT/spkg/base

Martin's patch was probably produced somewhere outside of the Sage
directory tree. But I think that doesn't matter in this case. To apply
a patch using "patch" and without using hg, you download the patch
file to the relevant directory and use the "patch" command. I admit
that doing something like this

patch < trac_7505.patch

is OK under Linux. But on Solaris, I have trouble using "patch" as the
above command is more chatty. It's a common experience, I think, of
people like myself who are transitioning to using non-GNU tools on
Unix.

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] conjugates in SR disappear

When using conjugate() in the symbolic ring some functions seem to
forget the conjugate:

----------------------------------------------------------------------
| Sage Version 4.3, Release Date: 2009-12-24 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: var('z')
z
sage: m=z*z.conjugate()
sage: m
z*conjugate(z)
sage: m.factor()
z^2
sage: m.simplify()
z^2


/Håkan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-check-64

William Stein wrote:
> On Tue, Dec 29, 2009 at 3:06 PM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> In $SAGE_LOCAL/bin/sage-check-64 it says the following.
>>
>> ---------------------------------------------------
>> # If SAGE64 is set to yes check if $SAGE_LOCAL/lib exists on Solaris as well as
>> # OSX since those are currently the only two platforms which require SAGE64. If
>> # it does not exist create the directory and then create a file sage-64.txt
>> # Eventually Linux PPC on the PS3 might need to be added here
>>
>> if [ "$SAGE64" = "yes" ]; then
>> CHECKFILE="no"
>> if [ `uname` = "SunOS" ]; then
>> echo "Building Sage on Solaris in 64-bit mode"
>> CHECKFILE="yes"
>> fi
>> if [ `uname` = "Darwin" ]; then
>> echo "Building Sage on OS X in 64-bit mode"
>> CHECKFILE="yes"
>> fi
>> if [ $CHECKFILE = "yes" ]; then
>> if ! [ -d "$SAGE_LOCAL"/lib ]; then
>> echo "Creating SAGE_LOCAL/lib since it does not exist"
>> mkdir "$SAGE_LOCAL"/lib
>> fi
>> echo "Creating SAGE_LOCAL/lib/sage-64.txt since it does not exist"
>> touch "$SAGE_LOCAL"/lib/sage-64.txt
>> fi
>> fi
>> --------------------------------------------
>>
>>
>> Is there any reason for limiting this check to Solaris and OS X now? Since the
>> comments suggest it might be needed on 'Linux PPC on the PS3', why not simply
>> have it work on every platform, if SAGE64 is set to yes? Can it do any harm?
>>
>> There are several platforms which support building 32 and 64 bit binaries -
>> Solaris, OS X, AIX, HP-UX and I guess from the above comments Linux PPC.
>>
>> I'd propose simply removing the checks for OS X and Solaris, and letting the
>> code work on any platform.
>>
>
> That sounds reasonable to me.
>
> William
>

Where does that file come from? It seems to magically appear in local/bin if one
builds Sage, but I've no idea where it is stored, and so what needs editing.

dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Producing patch - no working Sage

William Stein wrote:
> On Wed, Dec 30, 2009 at 9:59 AM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> John Cremona wrote:
>>> I regularly use Sage on a machine which either does not have its own
>>> hg, or has too old a version, and then I just use "sage -hg" to run
>>> Sage's own hg. That's after building Sage, of course.
>>>
>>> John
>> Yes, but the point was, on my Sun Ultra 27, Sage will not build. I have 'hg'
>> installed in /usr/bin though.
>>
>
> You should probably build hg from source yourself. It's best to use
> the same version that is included in Sage.

Yes, I'll do that. Installing 'hg' is no problem. If I can get Sage to build,
I'm sure I can manage 'hg'!

> You might also want to build differ if you want the -Naur flags to work.

I prefer to avoid GNUisms whenever possible.

> William
>

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Producing patch - no working Sage

On Wed, Dec 30, 2009 at 9:59 AM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> John Cremona wrote:
>> I regularly use Sage on a machine which either does not have its own
>> hg, or has too old a version, and then I just use "sage -hg" to run
>> Sage's own hg.  That's after building Sage, of course.
>>
>> John
>
> Yes, but the point was, on my Sun Ultra 27, Sage will not build. I have 'hg'
> installed in /usr/bin though.
>

You should probably build hg from source yourself. It's best to use
the same version that is included in Sage.

You might also want to build differ if you want the -Naur flags to work.

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org