[sage-devel] Re: round(), floor() and ceil() on interval objects
Well, I'm a little confused -- I thought that the whole point of floor() and ceil() was to return Integers. Indeed: In my opinion, this is a huge +1. Nick --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
Craig Citro wrote: So I think that this suggests returning an Integer is the right move -- it's just a question of what to do if there *is* no single correct integer. Okay, that seems like a valid point, though I still disagree. I think that we have two levels of consistency here: consistency with the function and consistency with the concept of interval arithmetic. I think that in this case, the interval arithmetic requirement is more specific, so you should be consistent with having intervals. So you say that if I have the interval X=[3.5, 3.7], and I'm interested in what possibilities there are for sin(floor(X)), then really there is only one possibility (however, it still makes sense to me to return an interval [sin(3), sin(3)]). You bring up that the real stickler of a question is something like: in the case that I have the interval X=[2.5, 4.5], what should sin(floor(X)) return? Maybe we should have a discrete version of interval objects, so I would get a list of values [sin(2), sin(3), sin(4)]? When we're trying to work with a function which takes a continuous range and maps it onto a discrete set of points, maybe we should be converting to a discrete version of interval arithmetic, i.e., a list of values that we treat like a discrete interval. Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
Okay, that seems like a valid point, though I still disagree. I think
that we have two levels of consistency here: consistency with the
function and consistency with the concept of interval arithmetic. I
think that in this case, the interval arithmetic requirement is more
specific, so you should be consistent with having intervals.
Well, I guess this depends on your point of view. Robert B. and I
chatted about this thread when it started, and I think he convinced me
that the right point of view is that RIF is supposed to be a model
of \mathbb{R} that keeps track of errors for you -- that RIF is a
drop-in replacement for, say, RDF, and that it keeps track of
precision as you go. From this point of view, I think there's no
question of what the behavior of floor() should be.
On the other hand, if you're just thinking of intervals as
intrinsically interesting objects, maybe this isn't as natural? I
guess I can just put the ball back in your court: Jason, what do
intervals mean to you? ;)
-cc
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
Craig Citro wrote:
Okay, that seems like a valid point, though I still disagree. I think
that we have two levels of consistency here: consistency with the
function and consistency with the concept of interval arithmetic. I
think that in this case, the interval arithmetic requirement is more
specific, so you should be consistent with having intervals.
Well, I guess this depends on your point of view. Robert B. and I
chatted about this thread when it started, and I think he convinced me
that the right point of view is that RIF is supposed to be a model
of \mathbb{R} that keeps track of errors for you -- that RIF is a
drop-in replacement for, say, RDF, and that it keeps track of
precision as you go. From this point of view, I think there's no
question of what the behavior of floor() should be.
On the other hand, if you're just thinking of intervals as
intrinsically interesting objects, maybe this isn't as natural? I
guess I can just put the ball back in your court: Jason, what do
intervals mean to you? ;)
I agree with Robert; at least, that is my use-case for using intervals
next semester in teaching numerical analysis.
I speak from a programmatic point of view, though. I'd like to not be
surprised that the following doesn't work:
a=sin(floor(RIF( (1.1,1.2) )))
a.lower()
a.upper()
versus
a=sin(floor(RIF((1.5,2.5
a.lower()
a.upper()
In other words, I don't think that the return type of floor() should
depend on how big the interval is.
If you are keeping track of errors, then I think floor(RIF(1.5, 2.5))
should return an interval (possibly a discrete analog, i.e., just the
integers [1,2] in a class that acts like an interval). Thus, I think
that floor(an interval in which all numbers have the same interval)
ought to return an interval, where both endpoints are the same.
Jason
--
Jason Grout
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
I speak from a programmatic point of view, though. I'd like to not be surprised that the following doesn't work: a=sin(floor(RIF( (1.1,1.2) ))) a.lower() a.upper() versus a=sin(floor(RIF((1.5,2.5 a.lower() a.upper() I'm a little confused -- *neither* of those would work. The proposal is that the return type of floor be Integer, just like it is for every other model of R. The only difference is that the second one would raise an exception, since there's no unique floor for [1.5, 2.5]. In other words, I don't think that the return type of floor() should depend on how big the interval is. I agree. The return type is Integer (whenever the function returns). -cc --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Sep 19, 2009, at 9:56 PM, Jason Grout wrote:
Craig Citro wrote:
Okay, that seems like a valid point, though I still disagree. I
think
that we have two levels of consistency here: consistency with the
function and consistency with the concept of interval arithmetic. I
think that in this case, the interval arithmetic requirement is more
specific, so you should be consistent with having intervals.
Well, I guess this depends on your point of view. Robert B. and I
chatted about this thread when it started, and I think he
convinced me
that the right point of view is that RIF is supposed to be a model
of \mathbb{R} that keeps track of errors for you -- that RIF is a
drop-in replacement for, say, RDF, and that it keeps track of
precision as you go. From this point of view, I think there's no
question of what the behavior of floor() should be.
On the other hand, if you're just thinking of intervals as
intrinsically interesting objects, maybe this isn't as natural? I
guess I can just put the ball back in your court: Jason, what do
intervals mean to you? ;)
I agree with Robert; at least, that is my use-case for using intervals
next semester in teaching numerical analysis.
I speak from a programmatic point of view, though. I'd like to not be
surprised that the following doesn't work:
a=sin(floor(RIF( (1.1,1.2) )))
a.lower()
a.upper()
Are you surprised that
sage: a = sin(floor(RDF(1.5)))
sage: a.prec()
doesn't work?
versus
a=sin(floor(RIF((1.5,2.5
a.lower()
a.upper()
In other words, I don't think that the return type of floor() should
depend on how big the interval is.
That's not what I was suggesting, I think it should be an exception
if there is not a unique floor. If you want all possible floors, you
can always do
sage: a = RIF(1.5, 2.5)
sage: floor(a.lower())
1
sage: floor(a.upper())
2
but I think this is the exception. In the typical case (small
diameter) there is one actual value, and it's known exactly (i.e.
there's no more error to keep track of).
If you are keeping track of errors, then I think floor(RIF(1.5, 2.5))
should return an interval (possibly a discrete analog, i.e., just the
integers [1,2] in a class that acts like an interval). Thus, I think
that floor(an interval in which all numbers have the same interval)
ought to return an interval, where both endpoints are the same.
A discrete analog would be interesting, though it quickly leads to a
combinatorial explosion of possibilities after a couple of arithmetic
operations. I still don't think it's the right answer though--it
forces people to handle the RIF differently than all other floating
point models we have, and makes RIF less useful as a drop-in
replacement.
- 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-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Sep 17, 2009, at 10:44 PM, Robert Bradshaw wrote: On Sep 17, 2009, at 3:16 PM, David Harvey wrote: I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. +1. The smallest possible value for floor is a different thing (and contains less information) than all possible values of floor, and all possible values characterizes the interval arithmetic operations. Example: sage: floor(log(RIF(8)) / log(RIF(2))) 3.? Should this be 2? What if it returned an Integer if there was a unique floor (ceiling, etc.) and raised an exception otherwise? - 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
Robert Bradshaw wrote: On Sep 17, 2009, at 3:16 PM, David Harvey wrote: I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. +1. The smallest possible value for floor is a different thing (and contains less information) than all possible values of floor, and all possible values characterizes the interval arithmetic operations. +1 to this reasoning, which means -1 for changing round() and friends. 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Fri, Sep 18, 2009 at 7:06 AM, Jason Grout jason-s...@creativetrax.com wrote: Robert Bradshaw wrote: On Sep 17, 2009, at 3:16 PM, David Harvey wrote: I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. +1. The smallest possible value for floor is a different thing (and contains less information) than all possible values of floor, and all possible values characterizes the interval arithmetic operations. +1 to this reasoning, which means -1 for changing round() and friends. Jason I feel like there is currently no natural way to get integers from intervals, which makes them quite frustrating and awkward to work with. I don't really care if the natural way is called round, but I want *something*. sage: a = RIF(1.5,2.3) sage: a.tab a.abs a.csch a.overlaps a.absolute_diameter a.dba.parent a.additive_ordera.diameter a.prec a.alea a.dump a.real a.algdepa.dumps a.relative_diameter a.arccosa.exp a.rename a.arccosh a.exp2 a.reset_name a.arccoth a.floor a.save a.arccsch a.fp_rank_diameter a.sec a.arcsech a.intersection a.sech a.arcsina.is_NaNa.simplest_rational a.arcsinh a.is_exact a.sin a.arctana.is_inta.sinh a.arctanh a.is_nilpotent a.sqrt a.base_extend a.is_onea.square a.base_ring a.is_unit a.square_root a.category a.is_zero a.str a.ceil a.log a.subs a.ceiling a.log10 a.substitute a.centera.log2 a.tan a.contains_zero a.lower a.tanh a.cos a.magnitude a.union a.cosh a.mignitude a.upper I see no way to easily get 1 2 or 3 from a. 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
Hello, sage: a = RIF(1.5,2.3) I see no way to easily get 1 2 or 3 from a. I propose, but I'm perhaps missunderstanding. a.lower().floor() a.upper().ceil() a.center().round() François --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Fri, Sep 18, 2009 at 9:53 AM, Francois Maltey fmal...@nerim.fr wrote: Hello, sage: a = RIF(1.5,2.3) I see no way to easily get 1 2 or 3 from a. I propose, but I'm perhaps missunderstanding. a.lower().floor() a.upper().ceil() a.center().round() I know about those and always eventually end up using them. But I don't consider them easy. -- 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
William Stein wrote: On Fri, Sep 18, 2009 at 9:53 AM, Francois Maltey fmal...@nerim.fr wrote: Hello, sage: a = RIF(1.5,2.3) I see no way to easily get 1 2 or 3 from a. I propose, but I'm perhaps missunderstanding. a.lower().floor() a.upper().ceil() a.center().round() I know about those and always eventually end up using them. But I don't consider them easy. How a new function, integer_range a.integer_range() returns [0, 1, 2, 3] or maybe just returns the iterator xrange(0,4) Then you could do something like a.integer_range()[0] 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
I propose, but I'm perhaps missunderstanding. a.lower().floor() a.upper().ceil() a.center().round() I know about those and always eventually end up using them. But I don't consider them easy. Maybe include them and call them something like ilower and iupper? I'm modeling this on isqrt: for a real number x, x.isqrt() is the largest integer less than x.sqrt(); here x.ilower() would be the largest integer less than x.lower(). -cc --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
So there are two things people could want from an interval i:
1) { floor(x) for x in i }
2) min { floor(x) for x in i }
I think that David's unhappy with floor doing (2). The other proposal
is to have x.floor() return the unique element in (1) when it's a
singleton, and raise an exception otherwise. David -- would you be
happy with that?
Then there's also the issue that both Nick and William would like to
have functionality for (2) easily available -- we just need to agree
on a name. Ideas?
Also, one should note that this still doesn't completely solve Nick's
problem -- if you have code that uses a RealField element x, and it
calls x.floor(), you can't necessarily drop RIF in for RealField,
because (1) above might have multiple elements. But as David and
Robert pointed out, there's not really a way around that without
breaking the validity of results using RIF. I think Nick's previous
reply suggests he's okay with this, though ...
-cc
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
Craig Citro wrote:
So there are two things people could want from an interval i:
1) { floor(x) for x in i }
2) min { floor(x) for x in i }
I think that David's unhappy with floor doing (2). The other proposal
is to have x.floor() return the unique element in (1) when it's a
singleton, and raise an exception otherwise. David -- would you be
happy with that?
I really think that floor, ceil, and round should return intervals when
they are fed intervals. I thought that was the whole point of interval
arithmetic.Shouldn't sin(floor(interval)) be an interval? It won't
be if floor automatically converts things to integers. Why should
floor, ceil, and round get special treatment to yank things out of
interval arithmetic? Why not other functions too? It seems that having
some functions that yank you out of interval arithmetic sort of spoil
everything.
I really like the idea that we should have separate ifloor, iceil, and
iround functions specifically on intervals that return integers, as
described.
That said, I don't use interval arithmetic very much at all (so my
points above are purely from a consistency point of view). However, I
do plan on using it in teaching numerical analysis next semester.
Thanks,
Jason
--
Jason Grout
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
I really think that floor, ceil, and round should return intervals when they are fed intervals. I thought that was the whole point of interval arithmetic. Shouldn't sin(floor(interval)) be an interval? It won't be if floor automatically converts things to integers. Why should floor, ceil, and round get special treatment to yank things out of interval arithmetic? Why not other functions too? It seems that having some functions that yank you out of interval arithmetic sort of spoil everything. Well, I'm a little confused -- I thought that the whole point of floor() and ceil() was to return Integers. Indeed: sage: x = 3.12312 sage: type(x) type 'sage.rings.real_mpfr.RealLiteral' sage: type(x.floor()) type 'sage.rings.integer.Integer' sage: x = RDF(x) sage: type(x.floor()) type 'sage.rings.integer.Integer' sage: x = RealField(100)(x) sage: type(x.floor()) type 'sage.rings.integer.Integer' So I think that this suggests returning an Integer is the right move -- it's just a question of what to do if there *is* no single correct integer. I really like the idea that we should have separate ifloor, iceil, and iround functions specifically on intervals that return integers, as described. Definitely. -cc --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Fri, Sep 18, 2009 at 7:13 PM, Craig Citro craigci...@gmail.com wrote: I really think that floor, ceil, and round should return intervals when they are fed intervals. I thought that was the whole point of interval arithmetic. Shouldn't sin(floor(interval)) be an interval? It won't be if floor automatically converts things to integers. Why should floor, ceil, and round get special treatment to yank things out of interval arithmetic? Why not other functions too? It seems that having some functions that yank you out of interval arithmetic sort of spoil everything. Well, I'm a little confused -- I thought that the whole point of floor() and ceil() was to return Integers. Indeed: sage: x = 3.12312 sage: type(x) type 'sage.rings.real_mpfr.RealLiteral' sage: type(x.floor()) type 'sage.rings.integer.Integer' sage: x = RDF(x) sage: type(x.floor()) type 'sage.rings.integer.Integer' sage: x = RealField(100)(x) sage: type(x.floor()) type 'sage.rings.integer.Integer' So I think that this suggests returning an Integer is the right move -- it's just a question of what to do if there *is* no single correct integer. A huge +1 to this! 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
2009/9/17 Jason Grout jason-s...@creativetrax.com: Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round- round the midpoint, floor - largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. What do people think? Should we close the ticket, or should we merge the patch (after possible rebasing). To illustrate: Currently: sage: R = RealIntervalField(100) sage: a = R(9.5, 11.3); a.str(style='brackets') '[9.500 .. 11.300710542735760101]' sage: floor(a).str(style='brackets') '[9.000 .. 11.00]' Proposed: sage: floor(a) 9 I would find this s useful! Whenever I compute with intervals, I often really want the integer floor, ceiling, or round. 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
William Stein wrote : 2009/9/17 Jason Grout jason-s...@creativetrax.com: Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round- round the midpoint, floor - largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. What do people think? Should we close the ticket, or should we merge the patch (after possible rebasing). To illustrate: Currently: sage: R = RealIntervalField(100) sage: a = R(9.5, 11.3); a.str(style='brackets') '[9.500 .. 11.300710542735760101]' sage: floor(a).str(style='brackets') '[9.000 .. 11.00]' I use computation over intervals in order to see the error x in a = x=9.5 or x=9.56 or x=11.2 or ... I test the function sin, the result of sin a = [-1..1] The value is 0.1 or 0.2 or -0.6 or. The a^2 operation is similar. So I prefer floor a = 9 or 10 or ... or 11, or [9..11]. Result is include in [9..11] min and max functions may be usefull if we want to get 9.5 and 11.3. F. Proposed: sage: floor(a) 9 I would find this s useful! Whenever I compute with intervals, I often really want the integer floor, ceiling, or round. 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-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On 17-Sep-09, at 12:53 AM, Jason Grout wrote: Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round- round the midpoint, floor - largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. I think I did all the work on that ticket, and yes, that was my reasoning. Nick --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. david On Sep 17, 3:53 am, Jason Grout jason-s...@creativetrax.com wrote: Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round- round the midpoint, floor - largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. What do people think? Should we close the ticket, or should we merge the patch (after possible rebasing). To illustrate: Currently: sage: R = RealIntervalField(100) sage: a = R(9.5, 11.3); a.str(style='brackets') '[9.500 .. 11.300710542735760101]' sage: floor(a).str(style='brackets') '[9.000 .. 11.00]' Proposed: sage: floor(a) 9 Thanks, Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Sep 17, 2009, at 3:16 PM, David Harvey wrote: I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. +1. The smallest possible value for floor is a different thing (and contains less information) than all possible values of floor, and all possible values characterizes the interval arithmetic operations. On Sep 17, 3:53 am, Jason Grout jason-s...@creativetrax.com wrote: Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round- round the midpoint, floor - largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. What do people think? Should we close the ticket, or should we merge the patch (after possible rebasing). To illustrate: Currently: sage: R = RealIntervalField(100) sage: a = R(9.5, 11.3); a.str(style='brackets') '[9.500 .. 11.300710542735760101]' sage: floor(a).str(style='brackets') '[9.000 .. 11.00]' Proposed: sage: floor(a) 9 Thanks, Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
