<mark_weaver>support for type tag checking would be fairly easy, and would be a huge win for dynamic language implementations. <mark_weaver>but for the most part, the changes would not be easy. very little about modern processor design is easy. <mark_weaver>also, I don't know that the floor rounding mode would take the exact same number of transistors as truncate toward 0. but the difference in implementation complexity would be totally trivial compared to the complexity of division. <bu^>mark_weaver, I don't see why you would expect rounding from a "idiv" operation <mark_weaver>and again, I'm not really blaming anyone. it's not the nature of things that C and processors would be optimized for each other in a self-reinforcing phenomenon. <bu^>I think idiv appeared before C <mark_weaver>bu^: what do you think happens when you divide two numbers whose quotient is not an integer? e.g. 10/3 ? <bu^>you want to compute a = p *q + b <bu^>if you get p and b the operation succeded <bu^>(so is my naive understanding from just a purely mathematica point of view) <bu^>anything else would be "strange" <bu^>even if more conveinient for practical use <mark_weaver>right, and if you put it that way, then the question is: what set of 'b's are allowed? there are an infinite number of solutions to that equation. <mark_weaver>each rounding mode corresponds, one-to-one, with a policy on what set of 'b's are allowed. <mark_weaver>davexunit: you mean support for large integers in the hardware? <davexunit>mark_weaver: big numbers in guile. totally unrelated to the hardware conversation. <mark_weaver>right, Guile supports arbitrary size integers transparently. <mark_weaver>bu^: with floor/, if the divisor is positive, then 'b' is always non-negative and less than the divisor. <bu^>but I mean all are exact integers, no rounding is involved, given (a, q) you just have one (p, b) couple given the constraint that b < p ? <bu^>now maybe you have to be carefull for negative numbers <mark_weaver>as you increase the dividend, 'b' goes around in a cycle: 0, 1, 2, 3, ... p-1, 0, etc. <bu^>didn't look for that <mark_weaver>with truncate, it's a mess. 'b's go around in a cycle until the dividend becomes negative, and then you have a whole new set of possible 'b's. <bu^>but how/where do you have the truncation operation ? <mark_weaver>this can lead to obscure bugs and security holes, and is very inconvenient for most kinds of discrete math, such as used in crypto. <bu^>I don't see where "idiv" truncates anything <mark_weaver>well, "rounding mode" is another way to think about the policy that chooses the set of possible 'b's. <mark_weaver>truncate means that the quotient is found by truncating everything after the decimal point. <bu^>no, it would be (3, 1) <mark_weaver>and then the remainder is whatever is needed to make your equation true. <bu^>you're talking about int => float => int conversion <bu^>that's another issue <bu^>that's how I understand it <bu^>and then I agree with you, int => float => int is a mess <bu^>but I think that it might be for technical reasons (historically) <mark_weaver>"truncation" does not refer to the way it's implemented in the hardware. of course there's never any floating-point representation that gets truncated. <mark_weaver>"truncation" merely refers to the policy of what the resulting quotient is, compared to what the exact rational answer would be. <bu^>(I first thought that you were talking about int => int division, but now I understand better) <mark_weaver>I see that you object to this way of thinking about things, which is fine. so let's not use the term "rounding mode". Perhaps you'll be more comfortable if we talk about the policy for what set of 'b's is allowed. <mark_weaver>"rounding mode" and "policy for how to choose which 'b' from the infinite set of possibilities". <bu^>well I prefere rounding mode <mark_weaver>most people prefer to talk about rounding mode though. <bu^>so that we understand that it is a cast from float back to int <bu^>with we talk about integer pairs it would refere to euclidian division for me, which has no rounding issues <mark_weaver>yes, euclidean/ is perhaps the nicest of all, where 'b' is always non-negative and less than the absolute value of the divisor. <mark_weaver>for floor/, 'b' is the same sign as the divisor (or zero) and its absolute value is less than the absolute value of the divisor. <mark_weaver>but to clarify: I'm talking about int->int division. I'm not talking about floor->int conversion. <bu^>ok, I understand that it is the result you want <bu^>but there are no such hardware instruction to do such <bu^>either you perform euclian, where you are only with integers, or you pass to float and then go back to int <mark_weaver>the hardware signed integer division instructions do not do euclidean division. I wish they did. <mark_weaver>if they did floor division, that would also be acceptable. <mark_weaver>but they do truncating division, which is a bad choice. <bu^>that's an interesting issue, btw once you have a float you can just use frndint to go back to the nearest (rounded) int <mark_weaver>(I wrote that part of the manual, as well as the implementations of the division operators themselves) <mark_weaver>look at the examples. see how they differ when negative numbers are involved. <mark_weaver>processor instructions tend to implement truncate/, truncate-quotient and truncate-remainder. <mark_weaver>(Guile's division operators also support non-integers, but you can pretend they don't and just focus on the integers) <bu^>I think I understand your point, but I think we were not talking about the same thing, I was refererring to was the CPU can/cannot do <bu^>the only divide operation for integers in asm is (i)div <bu^>which does not truncate anything and returns a pair of values with very well defined constrains so that the pair is unique (given the inputs) <bu^>otherwise for truncation or rounding you have to pass through float representation and go back to integers (I might be wrong, but didn't see any asm op doing all this in one step) <bu^>now default conversion behaviour is truncation <bu^>but you can also use frndint to round to nearest <mark_weaver>idiv(p,q) does the *equivalent* of producing the exact rational result of p/q and then truncating everything after the decimal point. <bu^>or use some tricks to avoid this and just discard the remainder <bu^>why would it truncte ? <mark_weaver>you're correct that it's not implemented that way in the hardware. but those are the semantics. <bu^>idiv return two integers <bu^>if you drop one you indeed truncate <bu^>but otherwise you either need to cast to float or "if" <bu^>which is a huge performance loss <bu^>now I better understand <bu^>sorry for taking so long <mark_weaver>I'm sorry that I'm failing to explain this, but I don't know how to be any more clear about it. <bu^>the point is just that there is no "hardware" truncation <bu^>it's the fact that the code doesn't use both informations from idiv <bu^>but doing otherwise would be a big performance loss <bu^>that's how I understand it no <mark_weaver>right, "truncate" is referring to the *semantics*, not the *implementation*, and it's referring to how the *quotient* is chosen. <bu^>hardware performs euclidian division <bu^>nothing more nothing less <mark_weaver>when you divide a/b to get q and r, it is not enough to say that a = q*b + r <mark_weaver>you can express that constraint in two different ways. <mark_weaver>you can either tell how to choose the 'r' from the infinite number of choices, or you can say how to choose 'q' compared with the exact rational result of a/b. <mark_weaver>for better or worse, most people prefer to express the constraint as a rounding mode, which tells the relation between 'q' and the exact rational a/b. <mark_weaver>I think you meant to write |r| < |b|, but actually that's not enough to make it unique. <mark_weaver>for euclidean division, the constraint is 0 <= |r| < |b| <mark_weaver>and that's a very nice constraint, with good properties, but that's not what processors do. <mark_weaver>idiv uses a different constraint that can't be expressed as nicely. <mark_weaver>the constraint that idiv uses is this: if a is positive, then 0 <= |r| < |b| <bu^>which is the correct mathematical definition <mark_weaver>no, for euclidean division, 0 <= r < |b| in all cases, regardless of the sign of a. <bu^>hum yes, which makes it ugly when you drop the remainder <bu^>ok, I'm going for sleep ***Sgeo is now known as 45PABBMIQ
*wingo also seeing segfaults occasionally while bootstrapping after the madvise MADV_DONTNEED patch <wingo>i'll track it down or back it out ***micro_ is now known as Guest25985
***Fuuzetsu is now known as Guest89559
***Guest89559 is now known as Fuuzetsu`
***bogdan_ is now known as 23LAA2AO5
***Fuuzetsu` is now known as Fuuzetsu
<mark_weaver>wingo: multiple random build problems showing up on master, on hydra. <mark_weaver>the problem shows itself as segfaults, usually while compiling .go files but sometimes while running the test suite. <mark_weaver>the first such segfault occurred after "Return unused parts of the stack to the OS" and before the following commits. ***haroldwu_ is now known as haroldwu
<wingo>yep, something wrong with that patch <wingo>i will track it down tonight or otherwise back out that patch ***araujo is now known as Guest65839
<impaktor>is geiser for Emacs some how related to swank/slime? <impaktor>...and is geiser what most people use for their scheme programming? <wingo>geiser is what most guile people use, if people use anything beyond a basic text editor <wingo>geiser is similar in some ways to swank/slime but is a separate independent project <taylanub>Been implementing a toy pseudo-Scheme to play with macro systems; halfway implemented something that moves the lexical scope of macros down into the run-time, before realizing it's quite a useless thing to do compared to how complex it is when actually compiling separately. :P <add^_>Well, it's a nice thing to learn anyway <taylanub>I never implemented a Scheme before, so profit. <add^_>Learn by doing is my favorite way of learning <wingo>nope, i really find it relaxing. <add^_>I should develop that... what would you call that? skill? <taylanub>I think it can be fun when one has good tools and can use them well. I have yet to get good at the Guile REPL, but I can only imagine it being much better than using lldb for Objective-C. <add^_>wingo, how do you develop the patience and feeling of relaxation of debugging? <add^_>It sounds like I'm trolling or something, but I'm actually being serious.. <wingo>civodul: i missed you all as well! <civodul>well you know, good, fast, tiring, furstrating, warm, and friendly <wingo>add^_: dunno, it's like cleaning sometimes, good and relaxing *add^_ kinda imagines a zen-garden with a monk sitting on a stone with a laptop with a lot of code on the screen ***add^_` is now known as add^_
<bu^>maybe he was thinking something like "playing in your room and doing crazy things and messing everything everywhere such thay you can't cross your room anymore; maybe in this case cleaning feels refreshing"