Forum

by Jocelyn Fiat (modified: 2016 Oct 21)

:: Welcome :: Forum

Eiffel related groups and forums:

Check the latest messages:

  • Apr 24
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    To complement the comment of Thomas, it makse sense to mention at this point the "new technique WebAssembly". It seems that the low-level bytecode format WebAssembly has the potential to complement (and maybe in long-term also to replace) JavaScript. The major web browsers such as Chrome,
  • Apr 21
    Error in Eiffel implementation of Burnikel and Ziegler algorithm 2

    I need another set of eyes to tell me what is wrong with my Eiffel implementation of Burnikel and Ziegler's division, specifically "Algorithm 2 - 3n/2n". The Eiffel feature is shown below. The type "like Current" is an ARRAYED_LIST [NATURAL_8]. In other words, the implementation uses digits (i.e. limbs) containing 8-bit values, so numbers are in base-256. A manual trace of a failing call follows. (Sorry the arguments are so large, but I cannot reproduce the error with shorter values.) Execution follows step 3b in this case.

    Here's the problem. The algorithm seems to be fine to Step 5, where the remainder "r" ends up with more digits then the divisor. I believe the error is in step 3b, perhaps with the call to feature `ones' which is "supposed" to supply a value that is "Beta^n - 1". (Maybe I do not understand B&Z's "Beta^n" notation.

    Here is the Eiffel code:

    three_by_two_divide (a, a3, b: like Current): TUPLE [quot, rem: like Current]
            -- Called by `two_by_one_divide'.  It has similar structure as
            -- `div_three_halves_by_two_halfs', but the arguments to this
            -- function have type {JJ_BIG_NATURAL} instead of like `digit'.
            -- See Burnikel & Zieler, "Fast Recursive Division", pp 4-8,
            -- Algorithm 2.
        require
            n_not_odd: b.count >= div_limit and b.count \\ 2 = 0
            b_has_2n_digits: b.count = a3.count * 2
            a_has_2n_digits: a.count = a3.count * 2
        local
            n: INTEGER
            a1, a2: like Current
            b1, b2: like Current
            tup: TUPLE [quot, rem: like Current]
            q, q1, q2, r, r1: like Current
            c, d: like Current
        do
            n := b.count // 2
                -- 1) Split `a'
            a1 := new_sub_number (n + 1, a.count, a)
            a2 := new_sub_number (1, n.max (1), a)
                -- 2) Split `b'.
            b1 := new_sub_number (n + 1, b.count, b)
            b2 := new_sub_number (1, n.max (1), b)
                -- 3) Distinguish cases.
            if a1 < b1 then
                    -- 3a) compute Q = floor ([A1,A2] / B1 with remainder.
                if b1.count < div_limit then
                    tup := school_divide (a, b1)
                else
                    tup := two_by_one_divide (a, b1)
                end
                q := tup.quot
                r1 := tup.rem
            else
                    -- 3b) Q = beta^n - 1 and ...
                q := ones (n)
                    -- ... R1 = [A1,A2] - [B1,0] + [0,B1] = [A1,A2] - QB1.
                r1 := a + b1
                if n > 1 then
                    b1.shift_left (n)
                else
                    b1.bit_shift_left (zero_digit.bit_count // 2)
                end
                r1.subtract (b1)
            end
                -- 4) D = Q * B2
            d := q * b2
                -- 5) R1 * B^n + A3 - D.  (The paper says "a4".)
            r1.shift_left (n)
            r := r1 + a3 - d
                -- 6) As long as R < 0, repeat
            from
            until not r.is_negative
            loop
                r := r + b
                q.decrement
            end
            check
                remainder_small_enough: r.count <= b.count
                    -- because remainder must be less than divisor.
            end
            Result := [q, r]
        ensure
       --   n_digit_remainder: Result.rem.count = b.count // 2
            quotient_has_correct_count: Result.quot.count <= b.count // 2
        end
    

    In the trace, the arrow points to a line I believe is bad, but I don't know what to do with it. Here is the trace:

    three_by_two_divide (a = [227,26,41,95,169,93,135,110], 
                         a3 = [92,164,19,39],
                         b =  [161,167,158,41,164,0,0,0]) 
    
        n := b.count // 2 = 4
            -- 1) Split `a'.
        a1 := new_sub_number (n + 1, a.count, a) = [227,26,41,95]
        a2 := new_sub_number (1, n.max (1), a) = [169,93,135,110]
            -- 2) Split `b'.
        b1 := new_sub_number (n + 1, b.count, b) = [161,167,158,41]
        b2 := new_sub_number (1, n.max (1), b) = [164,0,0,0]
            -- 3b) Q = beta^n -1 and ...
    --> q := ones (4) = [255,255,255,255]          <-- Is this the error?
            -- ... R1 = [A1,A2] - [B1,0] + [0,B1].
        r1 := a + b1 = [227,26,41,96,75,5,37,151]
        b1.shift_left (n) = [161,167,158,41,0,0,0,0]                        
        r1.subtract (b1) = [65,114,139,55,75,5,37,151]
        d := q * b2 = [163,255,255,255,92,0,0,0]
        r1.shift_left (n) = [227,25,135,184,172,220,37,151,0,0,0,0]   -- too big!
        r := r1 + a3 - d -= [227,25,135,184,8,220,37,152,0,164,19,39] -- too big!
    

    I know this is long, but any help is appreciated.

  • Apr 18
    Eiffel-Loop version 1.4.4 released
    https://github.com/finnianr/Eiffel-Loop/releases/tag/1.4.4 I haven't been absolutely meticulous in documenting all the fixes and changes in the release notes, but hopefully most of the important ones have been covered. Maybe I should keep a developers audio diary. -- Finnian -- SmartDevelopersU
  • Apr 13
    Re: [eiffel-users] Ordering `dispose'
    Ok, Thanks for the info. I think that I have some C code to write :( Good day, Louis M Le jeudi 13 avril 2017 03:40:37 UTC-4, Alexander Kogtenkov a écrit : > > > I presume that since {ITEM} have in it's attributes the object of type > {LIBRARY}, every {ITEM} would been collected before the
  • Apr 13
    Re: [eiffel-users] Ordering `dispose'
    This does not work. As soon as objects become unreachable, no order can be relied on for their disposal. The best way to do correct disposal is to make it explicit in Eiffel code and not to rely on DISPOSABLE at all. The latter should be used as a safety net for programming errors. In that case
  • Apr 13
    Ordering `dispose'
    Hello everyone. I have a problem with a segmentation fault caused by some `dispose' routine not running in the right order by the garbage collector. Here is the situation. In the C side, I have a library pointer that I create with a C function `create_library' and a C function `free_library' to
  • Apr 11
    What Eiffelers can learn from the Python community
    It used to be that the Python community relied on something called TkInter for their GUI needs. This can be thought of as the Vision2 of the Python world, as for a long time it was the defacto GUI SDK for Python. But then along came WxPython, a Python interface to WxWidgets. It took a while, but
  • Apr 11
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    There are GUI libraries on top of OpenGL: https://github.com/libglui/glui/wiki https://code.google.com/archive/p/begui Furthermore, the Khronos Group seems to be sufficiently stable to rely on in the long term: https://www.khronos.org Unfortunately, Khronos does not offer something like OpenGUI
  • Apr 09
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    Well, I think you've just identified the potential fork in the thread Tom :) The issues related to setting up EiffelStudio and the issues related to not having an efficient UI library may not necessarily be the same and separating them may actually help solving both problems. My earlier
  • Apr 08
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    I have not programmed in 10 years, but EiffelVision 3 is a project that would get me back into it. Jonathan Wilcox On 4/4/17 9:06 AM, Bertrand Meyer wrote: This is pretty much what we have now. There is a “handle” for every platform. (Sort of a bridge pattern, but used and in fact published
  • Apr 08
    Re: [eiffel-users] Eiffel style guidelines
    On my side, I like ending any comment with a period. Because when I see such comment via any tool, if I see the period I am sure this is the end of the main comment. Otherwise we never know if this was truncated, for instance just the first line of multiple lines comment. -- Jocelyn 2017-04-08
  • Apr 08
    Re: [eiffel-users] Eiffel style guidelines
    Doesn't work. The first line of a multi-line comment may still be a complete sentence (if it's a command - if it's a query then the old convention was to terminate with a semi-colon). On Sat, 8 Apr 2017 at 14:22 Jocelyn Fiat wrote: > On my side, I like ending any
  • Apr 08
    Re: [eiffel-users] Eiffel style guidelines
    I just want to correct Alexander on the description of what the Eiffel style guidelines used to say: * boolean queries: question, with a question mark. -- Is current object less than `other'? * other queries: starting with a noun, no verb, no period. -- Number of items * commands:
  • Apr 08
    Re[2]: [eiffel-users] Eiffel style guidelines
    When the style always using a period or a question mark at the end of every feature comment was discussed, I really did not like it to say in polite terms. The comments without any punctuation unless they were questions looked pretty reasonable to me. However, since then I changed my mind.
  • Apr 08
    Re: [eiffel-users] Eiffel style guidelines
    decision was taken in a discussion of the Ecma committee (although such rules are beyond the language standard) in favour of consistency. I don't remember such discussion. I could not find anything in the minutes. -- Eric Bezault mailto:er...@gobosoft.com http://www.gobosoft.com
  • Apr 08
    RE: [eiffel-users] Eiffel style guidelines
    I do not remember the exact time (or can be sure 100%) but think the decision was taken in a discussion of the Ecma committee (although such rules are beyond the language standard) in favour of consistency. -- BM -----Original Message----- From: eiffel...@googlegroups.com [mailto:eiffel...@go
  • Apr 08
    RE: [eiffel-users] Eiffel style guidelines
    I think “uniformity” was the intention. Peter Horan From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Colin Adams Sent: Saturday, 8 April 2017 17:18 To: eiffel...@googlegroups.com Cc: me...@inf.ethz.ch Subject: Re: [eiffel-users] Eiffel style guidelines
  • Apr 08
    Re: [eiffel-users] Eiffel style guidelines
    Consistent with what? Certainly not consistent with existing code. On Sat, 8 Apr 2017 at 08:08 Bertrand Meyer wrote: > I do not remember the exact time (or can be sure 100%) but think the > decision was taken in a discussion of the Ecma committee (although such > rules
  • Apr 08
    Eiffel style guidelines
    Hello, In the Eiffel literature it is said that the header comment of a non-boolean query should look like this: count: INTEGER -- Number of items with no period at the end. But I can see that more and more classes written by ISE use different style guidelines:
  • Apr 06
    Error with If Statment in Liberty/ISE Eiffel
  • Apr 05
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    Another aspect to remember is that while the EiffelVision concept is good, it doesn't go nearly far enough in providing an efficient UI library - i.e. the top API. Myself and others here have slowly built up various higher-level complex controls over the years to make EV2 programming tolerably
  • Apr 04
    RE: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    Basic, low-level drawing primitives. -- BM -----Original Message----- From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Joe Abbate Sent: 04 April 2017 18:27 To: eiffel...@googlegroups.com Subject: Re: Macintosh version -- RE: [eiffel-users] Binary Mac
  • Apr 04
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    Regarding the balance between reuse and being dependent on somebody else to have updates to the platform, using an IDE platform may be an option. I've done tooling based on the Eclipse platform and despite its various problems, it has been a solid choice for lots of software tools and more
  • Apr 04
    RE: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    This is pretty much what we have now. There is a “handle” for every platform. (Sort of a bridge pattern, but used and in fact published before the term “bridge” was devised.) -- BM From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Davide Grandi Sent: 04
  • Apr 04
    Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
    Excuse my ignorance, in particular about the history behind Eiffel choosing GTK on the Mac, but if I'm not mistaken, in GUIland, aren't you always dependent on someone else's technology? I mean, for example on Windows, you'll write to the Windows API, right? So the question becomes what to do
  • See more ...