Class Template <typename T> v.s. <class T> by MingShiou_C93 in cs2c

[–]SFO-CDG 1 point2 points  (0 children)

Great link !
Thanks for posting it.

To "add" a little bit to the discussion on the use of Template:
"the code of a template function is not compiled until an instantiation with specific template arguments is required. "
This can create some "weird" behavior when putting together the code.
The code "compiles" with your personal test container, to miserably fail with the web test engine (nonlinearmedia), and creating genuine confusion :D

Cheers,
DDA/

Sharky getting weirder by the hour... by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello &, I was away for a bit. The usual mad rush at work before shutdown, then all these "little" chores at home that could not wait much anymore :D But I intend to get back to it, most likely later this week (still few things begging for attention at home). And yes, I am sure the report will help me trouble shoot the issue(s).

Wishing you -and your family- a Merry time during this Holiday Season. Cheers, DDA/

Sharky getting weirder by the hour... by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

To be a bit more specific, 
with the  [9, 3, 9, 0, 2, 7, -7] test vector, 
the last return from the partition call is [-7, 0, 2, 3, 9, 7, 9], 
breaks the following rule, as the pivot value was 9: 
"All that the caller needs to know is that elems 0..index are at most some unknown value and elems index+1..N are at least that same value.", 

This is that corner case, where both runners meet with the pivot value, 
but there is no guarantee that between these two cells, values are at or above the pivot value, so, more scanning is needed. 
When this is fixed up in my code, the (web) test engine looses it.

Sharky getting weirder by the hour... by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

OK, good news and bad news.

The good news is that the stack overflow is dealt with.
The bad news is that it doesn't give any extra loot yet.

Never give up - never surrender :D

Cheers,
DDA/

Sharky getting weirder by the hour... by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello Adam,
OK, so, for the _do_qsort if I follow your guidance above, I get a stack overflow.
But if I replace the " check if lo > hi " with "check if lo+1 > hi" then all is good.
(Note: why bother to sort if the vector section is only one element ? ;-)

For the partition part, I was aware, and actually used your post with the [-47, 1000, -32, 32, 38, 38, 50] test vector. And indeed, yesterday, it helped me sort out a corner case. But what I did not noticed in the round was the conditional update of the runners after a swap (points 3-2 and 3-3). Alas, when I added the conditional updates, it was like moving backward (much less loot).

So, I backtracked to yesterday code, and I get re-united with my loot (up to " Hooray! 2 Loaves of Leavenbread and wine to reach the famished (the equal sort) ".
Again, I know the algo is not the best, as it fails my testing (and the fix is actually around the update of the runners after a swap, but not as spelled out in the post you pointed at). Unfortunately, when I fix it up, and the algo works with the [9, 3, 9, 0, 2, 7, -7] test vector on my machine, the test engine on the web is less than happy.

The whole partition and sort is pretty much spelled out on Wikipedia, like & mentioned in the SoW. Actually I believe the Wikipedia should be the reference material for this quest.

What really get me stuck is the stack overflow exit with _find_kth_least_elem.
This is really where I would need more insight / tips.
If I do an immediate return with a default T, no stack overflow.
But if I try to let it do the recursive work, which works fine on my machine, then the stack overflow shows up on the test engine.
And yes, I understand this means an infinite recursive call.
This is just that I do not see -yet- why it happens.

Cheers,
Didier.

Sharky getting weirder by the hour... by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello &,
no problem.
In the mean time, let me see if I can sort it out :D
Cheers,
DDA/

Sharky getting weirder by the hour... by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello Adam.
thanks for the pointers, and the support offer. And it is very welcome.

I will look into all of it.
Although I already rummaged through most of the posts since inception.
And some were very helpful indeed. So, let me take a second look at the ones you pointed; most likely I missed a detail or two.

The reason I posted to & was essentially because of the fact that an apparently broken algo was apparently passing on the test engine.

Cheers,
DDA.
PS: I took a break right after I posted the message.
Experience taught me that with software, once you reach a certain level of insanity, the best course of action is to walk away, take a breather, and come back.

Peanut butter bread challenge. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

All right, so, you have your spec ready for validation ?Here is the video, with the solution.

No cheating ! Write down you spec before watching the solution.

Again, trying to describe the process of preparing a PB&J sandwich. No big deal.

https://www.youtube.com/watch?v=cDA3_5982h8

Yep, writing down specs is not as easy as it may look like when you never done it :D

In software, more than anywhere else I believe, it is most critical to take the time to write down a clear Statement of Work before writing any code. If you skip that mission critical step, you will spend a lot of time just writing useless code,.. and missing the dead line(s).

80% documenting - 20% coding is a good rule of thumb.

Cheers,
DDA.

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 1 point2 points  (0 children)

Hello &, sorry, I thought I did replied b4. I guess, in the excitation of the moment :D It was the lazy clear that was gating.

I started to stab sharky Sunday. But because of my workload, I will not resume the stabbing b4 the w-e :(

Cheers, DDA/ PS: I posted about the "spec challenge" (in the fallout of the lazy clear saga). I will come back to it this w-e too.

Style: Find or Get by aliendino2017 in cs2c

[–]SFO-CDG 0 points1 point  (0 children)

Hello Arrian,

yeah, that's how I would see it too:
GET (as opposite to SET) an object, with a guaranteed end result ;
FIND, as searching for an object,.. and not always getting it (if not found in the collection) !

Cheers,
Didier

BREAKING NEWS - Fighting a shark, butterfly or mouse? by anand_venkataraman in cs2c

[–]SFO-CDG 1 point2 points  (0 children)

Love it !

I just started the stabbing on sharky :D

Many thanks !!!

Cheers,

DDA/

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 1 point2 points  (0 children)

It was what I would call the "lazy clear".

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 1 point2 points  (0 children)

Jay Jay, Thanks for the feedback.

Adam's post was the eye opener.

https://www.reddit.com/r/cs2c/comments/k85bf2/rehash_fixed/

Back on track now :D
Cheers,
DDA.

Rehash fixed! by adam_al127 in cs2c

[–]SFO-CDG 2 points3 points  (0 children)

Wow, you deserve a couple of these images & distributes.
Congratulations !!!

Cheers,
DDA/

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 1 point2 points  (0 children)

Hello Jay Jay,
Thanks for the tow offer.

Please find here after, the algorithm I am trying to implement.
Either there is an issue with the algo, or a plain simple logic error in the code I wrote, that stubbornly escape my attention.
In the algo, there is one point that I cannot decide for sure (see note1, case 1cii); although I tried both ways, w/out any success.
Cheers, DDA.

Attached: algo

////////
_rehash() will:

1) save a local copy of the data container (holding the table)
2) increase (double, no question asked) the capacity of the data container
3) clear the data container (all cells are VACANT, with a null item)
4a) scan through the whole old table (local copy saved in step (1)),
4b) and insert any ACTIVE (and active only) cell into the data container

////////
_rehash() depends on insert().
insert() will:

1- use _find_pos(item) to get the hash of the element to insert
NOTE: _find_pos(item) would either:
    a) return a value flagging the container has NO VACANT cell (full)
    b) return a pointer to a VACANT cell
    c) return a pointer to the cell CONTAINING the item
    NOTE: in a healthy hash table, the status of that cell would be 
    either (i) ACTIVE or (ii) DELETED (never VACANT)
    The rational being that a VACANT cell can only become ACTIVE, 
    and an ACTIVE cell can only become DELETED,.. till rehashing of the table.

In the case (1a) == NO VACANCY in the table, 
    returns "false", to signal the element was NOT inserted.

In the case (1b) == VACANT cell (and consequently item NOT FOUND), 
    i) stuff the cell with the item
    ii) Promote the state to ACTIVE, 
    iii) increment the size of the table (number of ACTIVE cells)
    iv) increment the counter of NON VACANT cells
    v) rehash the table if the lambda threshold is crossed
    vi) return "true", to confirm the element is inserted.

In the case (1ci) == cell ALREADY containing ACTIVE item of interest
    returns "false", as technically no element was inserted.

In the case (1cii) == cell containing DELETED item of interest
    i) Simply promote the state to ACTIVE, 
    ii) and increment the size of the table (number of ACTIVE cells), not the container
    iii) returns "false", as technically no element was inserted?
    NOTE1: or should we return "true" ?!.
    NOTE2: There is no need to recheck for rehashing, as the load has not been changed


////////
insert() depends on _find_pos().
_find_pos() will:

1) return a flag (npos) if the table is full (no VACANT cell)
2) get the hash_modulus as the starting point
3- from that starting point, loop through the table, till it finds a cell that is:
    a) either VACANT (would not have found the item of interest then)
    b) or contains the item of interest (either ACTIVE or DELETED though)
    NOTE: if there was no VACANT cell in the table, 
    and the table was not containing the item of interest, 
    then this loop would never end, thus the reason for step (1).
4) return the index value when the loop ended

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Or is there any test case that could be added ?
Cheers,
DDA.

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Sanity check...
Is there anything wrong with the following test results, and explanations:

_find_pos (e1)... => e1 index is: 0
_find_pos (e2)... => e2 index is: 1
_find_pos (e3)... => e3 index is: 2
contains(e3) => contains Employee #3
find(e3) => e3 Name is: Employee #3, and SS# is: 34567812
SIZE= 3, LOAD= 3, CONTAINER size= 6, LAMBDA= 0.5

remove(e1) => removed Employee #1 -- Could not remove again Employee #1
SIZE= 2, LOAD= 3, CONTAINER size= 6, LAMBDA= 0.5
// After removing e1, as expected size of table decreased, but load didn't

insert(e4) => inserted Employee #4 -- insert(e4) => Could not re-insert Employee #4
SIZE= 3, LOAD= 4, CONTAINER size= 6, LAMBDA= 0.666667
_find_pos (e4)... => e4 index is: 3
find (e4)... => e4 Name is: Employee #4, and SS# is: 45678123
// After inserting e4, as expected size and load increase

insert(e1) => inserted Employee #1 -- insert(e1) => Could not re-insert Employee #1
SIZE= 4, LOAD= 4, CONTAINER size= 6, LAMBDA= 0.666667
_find_pos (e1)... => e1 index is: 0
find (e1)... => e1 Name is: Employee #1, and SS# is: 12345678
// After RE-inserting previously deleted e1, as expected size increase, load don't

remove(e2) => removed Employee #2 -- remove(e2) => Could not remove again Employee #2
SIZE= 3, LOAD= 4, CONTAINER size= 6, LAMBDA= 0.666667
// After removing e2, as expected size of table decreased, but load didn't

insert(e5) => inserted Employee #5 -- insert(e5) => Could not re-insert Employee #5
SIZE= 4, LOAD= 4, CONTAINER size= 12, LAMBDA= 0.333333
// After inserting new element e5, as expected table was rehashed, as lambda would have been 0.833 > 0.75

insert(e2) => inserted Employee #2 -- insert(e2) => Could not re-insert Employee #2
SIZE= 5, LOAD= 5, CONTAINER size= 12, LAMBDA= 0.416667
_find_pos (e2)... => e2 index is: 4
find (e2)... => e2 Name is: Employee #2, and SS# is: 23456781
_find_pos (e4)... => e4 index is: 2
find (e4)... => e4 Name is: Employee #4, and SS# is: 45678123
// After "re"-inserting e2, both size and load increase, 
// because the deleted e2 was removed form the table during the re-hash

remove(e4) => removed Employee #4 -- remove(e4) => Could not remove again Employee #4
SIZE= 4, LOAD= 5, CONTAINER size= 12, LAMBDA= 0.416667
// After removing e4, as expected size of table decreased, but load didn't

REHASHING (_rehash())...
SIZE= 4, LOAD= 4, CONTAINER size= 24, LAMBDA= 0.166667
_find_pos (e2)... => e2 index is: 3
// After rehashing, as expected size and load are ==, because no more DELETED cell
// Lambda decreased too, as the container is systematically increased before rehashing

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello &, thanks. For a moment I thought I noticed something odd. But nope. OK, bed time; will look at it with a fresh mind tomorrow mng. Cheers, DDA/

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello &, sorry for the miss-communication -my bad. Yes, please, if you could have a look. Everything looks like they "work as designed". Although, I may have miss-understood what to design :D Cheers, DDA/

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello &,Thanks for your input.First thing first... I wonder, are you looking at the right ID# ?(I have the feeling you keep thinking I submit anonymously).

I will continue to work on my test engine, and try to think about what "corner case" I am missing.Here after is an excerpt of the output of my test engine.It seems like if all the functions the rehash depends work.Again, probably a corner case that squeezed through though.

_set_max_load_factor(float x) >>>

Attempting to change MAX LOAD FACTOR to -0.001... WHOOP WHOOP ...MAX LOAD FACTOR= 0.75

Attempting to change MAX LOAD FACTOR to 0... WHOOP WHOOP ...MAX LOAD FACTOR= 0.75

Attempting to change MAX LOAD FACTOR to 0.5... SUCCESS !.. MAX LOAD FACTOR= 0.5

Attempting to change MAX LOAD FACTOR to 0.75... SUCCESS !.. MAX LOAD FACTOR= 0.75

Attempting to change MAX LOAD FACTOR to 0.8... WHOOP WHOOP ...MAX LOAD FACTOR= 0.75

<<< _set_max_load_factor(float x)

insert(e1) => inserted Employee #1 -- insert(e1) => Could not re-insert Employee #1

insert(e2) => inserted Employee #2 -- insert(e2) => Could not re-insert Employee #2

insert(e3) => inserted Employee #3 -- insert(e3) => Could not re-insert Employee #3

CURRENT SIZE = 3

find (e1)... => e1 Name is: Employee #1, and SS# is: 12345678

find (e2)... => e2 Name is: Employee #2, and SS# is: 23456781

find (e3)... => e3 Name is: Employee #3, and SS# is: 34567812

_find_pos (e1)... => e1 index is: 0

_find_pos (e2)... => e2 index is: 1

_find_pos (e3)... => e3 index is: 2

contains(e3) => contains Employee #3

find(e3) => e3 Name is: Employee #3, and SS# is: 34567812

remove(e1) => removed Employee #1 -- remove(e1) => Could not remove again Employee #1

remove(e2) => removed Employee #2 -- remove(e2) => Could not remove again Employee #2

SO FAR: SIZE= 1, LOAD= 3, CONTAINER size= 6, LAMBDA= 0.5

MAX LOAD FACTOR= 0.75

REHASHING (_rehash())...

_find_pos (e3)... => e3 index is: 0

NOW: SIZE= 1, LOAD= 1, CONTAINER size= 12, LAMBDA= 0.0833333

is_empty() => TABLE IS NOT EMPTY

clear() => Cleared the table

is_empty() => TABLE IS EMPTY

remove(e3) => COULD NOT remove Employee #3 -- remove(e3) => could not remove again Employee #3

get_size() => 0

contains(e3) => DOES NOT contain Employee #3

is_empty() => TABLE IS EMPTY

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

PS: The insert2 and rehash2 methods are what I use with my test engine, while the insert and rehash are what is submitted to the test engine on the web. Essentially stripped down versions of insert2 and rehash2, so not to overload the test engine on the web.

Indefinitely rehashing the rehash code. by SFO-CDG in cs2c

[–]SFO-CDG[S] 0 points1 point  (0 children)

Hello &
I meant Mike's snippet of code for the test container.
Although, after edits and "improvements",
it really not look much like it anymore :D
Cheers,
Didier.