Re: [racket-dev] [racket] Question about round
On Oct 1, 2011, at 12:54 AM, David T. Pierson wrote: On Fri, Sep 30, 2011 at 11:59:25AM -0400, Vincent St-Amour wrote: Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). It is not clear to me from the responses to this proposal whether it is still being considered. If so I feel motivated to question it. ... So the original confusion was due to round returning an inexact? number. The above proposal does not address that confusion, but instead makes integer? return #f for inexact? inputs. So: (integer? 1.0) ; would be #f I think Vincent was proposing that round continue to return an integer (which makes sense -- that is its raison d'etre) but that all integers be exact. At present, round always returns an integer, but this integer is exact only if the input was exact. (Correction: round does NOT always return an integer, e.g. (round +inf.0) . There are probably other counterexamples, but I haven't thought of them.) Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
On Sep 30, 2011, at 11:59 AM, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing Is it MATHEMATICALLY confusing, or is it confusing because most of us were brought up (in CS) with integer meaning 32-bit two's-complement binary representation of an integer? The English language uses inexact integers all the time. It's about 5 miles. It'll take about twenty minutes. Set your oven to 350 degrees. All of those are continuous physical quantities that happen to have been measured to an accuracy of 1 or more; it could actually be higher or lower by up to a mile, or several minutes, or about ten degrees, respectively. One could even say There are about fifty students in the class. In this case, I am 100% sure that the number of students is an integer, but less than 100% sure that that integer is 50. How would you represent this number? If you say it's not an integer because it's not exact, you've allowed for fractional students. If you say it must be exact because it's an integer, you've pretended to greater confidence than is justified. Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
At Sat, 1 Oct 2011 12:41:26 -0400, Stephen Bloch wrote: I think Vincent was proposing that round continue to return an integer (which makes sense -- that is its raison d'etre) but that all integers be exact. At present, round always returns an integer, but this integer is exact only if the input was exact. Not exactly. I wasn't suggesting any change to `round'. I was suggesting changing `integer?' to only return true for exact integers. This means that the results of `round' would usually not return true when passed to `integer?', but they could still be considered inexact integers. But anyway, there is enough opposition to the proposal that things are unlikely to change, at least for now. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
This is my opinion, too. Robby On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
I sent this to Matthew privately but I think we need to be much more careful with 'interesting'. While you are right about the 'wired into our code' part, I think the two of you are wrong about the 'interesting' part. From a type perspective, the numeric tower comes with major flaws and it would be wonderful if a language that divorces itself from the old flawed Scheme world could make a clean cut and do better. But I am also the person who preaches 'the path from here to there' and agree that the 'wired' argument for the existing code base and outside consumers tells us that Racket isn't the language that can fix these mistakes. On Sep 30, 2011, at 12:32 PM, Robby Findler wrote: This is my opinion, too. Robby On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
On Fri, Sep 30, 2011 at 12:28 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I sent this to Matthew privately but I think we need to be much more careful with 'interesting'. While you are right about the 'wired into our code' part, I think the two of you are wrong about the 'interesting' part. From a type perspective, the numeric tower comes with major flaws and it would be wonderful if a language that divorces itself from the old flawed Scheme world could make a clean cut and do better. I didn't mean to say that this wasn't interesting. The uninteresting thing, in my mind, is coping with the fallout of the specific changes that Vincent proposed. Some larger effort at a better design is whole different beast. Robby But I am also the person who preaches 'the path from here to there' and agree that the 'wired' argument for the existing code base and outside consumers tells us that Racket isn't the language that can fix these mistakes. On Sep 30, 2011, at 12:32 PM, Robby Findler wrote: This is my opinion, too. Robby On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
Vincent's proposal seemed to me to be just a renaming the current functions. Is there an intended change to the numeric tower that I'm missing? At Fri, 30 Sep 2011 13:28:12 -0400, Matthias Felleisen wrote: I sent this to Matthew privately but I think we need to be much more careful with 'interesting'. While you are right about the 'wired into our code' part, I think the two of you are wrong about the 'interesting' part. From a type perspective, the numeric tower comes with major flaws and it would be wonderful if a language that divorces itself from the old flawed Scheme world could make a clean cut and do better. But I am also the person who preaches 'the path from here to there' and agree that the 'wired' argument for the existing code base and outside consumers tells us that Racket isn't the language that can fix these mistakes. On Sep 30, 2011, at 12:32 PM, Robby Findler wrote: This is my opinion, too. Robby On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
Yes, there is. The type Integer would denote the exact integers now. In general, I wanted to this email into a larger context. On Sep 30, 2011, at 2:01 PM, Matthew Flatt wrote: Vincent's proposal seemed to me to be just a renaming the current functions. Is there an intended change to the numeric tower that I'm missing? At Fri, 30 Sep 2011 13:28:12 -0400, Matthias Felleisen wrote: I sent this to Matthew privately but I think we need to be much more careful with 'interesting'. While you are right about the 'wired into our code' part, I think the two of you are wrong about the 'interesting' part. From a type perspective, the numeric tower comes with major flaws and it would be wonderful if a language that divorces itself from the old flawed Scheme world could make a clean cut and do better. But I am also the person who preaches 'the path from here to there' and agree that the 'wired' argument for the existing code base and outside consumers tells us that Racket isn't the language that can fix these mistakes. On Sep 30, 2011, at 12:32 PM, Robby Findler wrote: This is my opinion, too. Robby On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
Doesn't it already? The docs say `Integer' includes only integers that are exact numbers, corresponding to the predicate `exact-integer?'. Even if the type were currently `Exact-Integer', it sounds like you mean just renaming to `Integer'. I think a change to the number hierarchy would mean changing functions so that they produce different results on particular inputs than they do now. That doesn't seem to be a part of Vincent's suggestion. At Fri, 30 Sep 2011 14:02:50 -0400, Matthias Felleisen wrote: Yes, there is. The type Integer would denote the exact integers now. In general, I wanted to this email into a larger context. On Sep 30, 2011, at 2:01 PM, Matthew Flatt wrote: Vincent's proposal seemed to me to be just a renaming the current functions. Is there an intended change to the numeric tower that I'm missing? At Fri, 30 Sep 2011 13:28:12 -0400, Matthias Felleisen wrote: I sent this to Matthew privately but I think we need to be much more careful with 'interesting'. While you are right about the 'wired into our code' part, I think the two of you are wrong about the 'interesting' part. From a type perspective, the numeric tower comes with major flaws and it would be wonderful if a language that divorces itself from the old flawed Scheme world could make a clean cut and do better. But I am also the person who preaches 'the path from here to there' and agree that the 'wired' argument for the existing code base and outside consumers tells us that Racket isn't the language that can fix these mistakes. On Sep 30, 2011, at 12:32 PM, Robby Findler wrote: This is my opinion, too. Robby On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good change for the next language, but not for `#lang racket'. As confusing as the current `integer?' may be, I think its definition is deeply wired into our code, tests, and documentation. I may guess wrong, but my best estimate of the hassle for this change is that it's too much trouble for too little payoff, and we could spend our energy on more interesting things. At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: On a more general note, do we really need inexact integers? The behavior of `integer?' is confusing, and I don't see especially compelling reasons to keep it this way. The subject comes up every couple of months on the mailing list, so we should do something about it. Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). `positive-integer?' and `nonnegative-integer?' are added as equivalents to their `exact' counterparts. `inexact-integer?' is added, to cover for the use case of checking is an inexact number has been rounded. I volunteer to implement this if we agree that this is the right thing. Vincent At Fri, 30 Sep 2011 07:16:22 -0600, Doug Williams wrote: Another such annoyance is than (min 1 +inf.0) = 1.0 - because if any argument is inexact, the result is inexact. I don't think this makes sense in the case of infinities. Infinities are very useful as initial values for things that are being minimized or maximized, but there is always the need for inexact-exact to protect against the (unexpected) coercion. This is all from the original R5RS and continued in R6RS - but, we aren't that language. Could we get an exception to the coercions in the case of +/-inf.0? Or an alternative min/max that don't do it? On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: exact-round is preferred. On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: Yesterday, Ryan Culpepper wrote: The pragmatic answer is you generally have to write (inexact-exact (round x)) which is annoying, but no one has yet bothered to add a standard library function for this, as far as I know. [From the annoyed side, especially since that thing tends to come in bunches which can make some quick code look much heavier than it is:] Maybe it's time to add something for that? `eround'? (But even `exact-round' would be better than the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related
Re: [racket-dev] [racket] Question about round
At Fri, 30 Sep 2011 11:31:47 -0500, Robby Findler wrote: Just to clear up one more possible point: the rational? predicate actually recognizes inexact numbers, eg: [robby@penghu] ~/git/plt/collects/drracket/private$ racket Welcome to Racket v5.1.3.9. (rational? (sqrt 2)) #t This is probably less problematic than `integer?', since `rational?' is (I assume) less used. But this is the same problem. If we decide to change one, we should change both. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
And, how about adding finite? and its ilk from r6rs into #lang racket. I have them in science/math, but they are probably core level routines. I had mentioned before that we probably should see what from science/math might be more useful in the core. On Fri, Sep 30, 2011 at 12:22 PM, Vincent St-Amour stamo...@ccs.neu.eduwrote: At Fri, 30 Sep 2011 11:31:47 -0500, Robby Findler wrote: Just to clear up one more possible point: the rational? predicate actually recognizes inexact numbers, eg: [robby@penghu] ~/git/plt/collects/drracket/private$ racket Welcome to Racket v5.1.3.9. (rational? (sqrt 2)) #t This is probably less problematic than `integer?', since `rational?' is (I assume) less used. But this is the same problem. If we decide to change one, we should change both. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
Here is what I meant: Integer in TR corresponds to exact-integer? (viewed as a predicate), and integer? in R may or may not map to Integer or Float in TR. There are more such anomalies. But let's rest the case here. Too much email for one day On Sep 30, 2011, at 2:17 PM, Vincent St-Amour wrote: At Fri, 30 Sep 2011 12:08:07 -0600, Matthew Flatt wrote: Doesn't it already? The docs say `Integer' includes only integers that are exact numbers, corresponding to the predicate `exact-integer?'. Even if the type were currently `Exact-Integer', it sounds like you mean just renaming to `Integer'. I think a change to the number hierarchy would mean changing functions so that they produce different results on particular inputs than they do now. That doesn't seem to be a part of Vincent's suggestion. You are correct. My proposal only involves renaming functions, and introducing a couple of new ones. The goal of that proposal is not so much to change the Racket numeric tower, but rather to clear up the confusion regarding what's an integer and what's not, to align it better with what (I believe) users expect. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
Hi all, I'm hoping that non-developers [of Racket itself] are welcome to post here. On Fri, Sep 30, 2011 at 11:59:25AM -0400, Vincent St-Amour wrote: Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). It is not clear to me from the responses to this proposal whether it is still being considered. If so I feel motivated to question it. Quoting the original poster in his follow-up email: On Fri, Sep 30, 2011 at 09:18:26AM -0700, Mark Engelberg wrote: When I saw in the docs for round that it returns an integer, and I was getting an inexact number, I was sure it was a mistake. So the original confusion was due to round returning an inexact? number. The above proposal does not address that confusion, but instead makes integer? return #f for inexact? inputs. So: (integer? 1.0) ; would be #f Are Racket users confused by the current result of (integer? 1.0) = #t? The original poster explicitly wrote that he expected #t from (integer? (round (sin 30))). It seems to me this proposed change would increase confusion. Maybe the concern is that integer? is unreliable for inexacts, so the proposed changes are safer? As Vincent pointed out in a follow-up email, if (integer? 1.0) should be #f then (rational? 1.0) should also be #f. Essentially integer? becomes useless for inexacts and rational? becomes a synonym for exact?. The utility of both functions decreases. It seems to me that the appropriate response to the original confusion is education/documentation, not a change in the semantics of the language which decreases utility and breaks backward compatibility. David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
