## Latest Comments

I apologize about the link.

I will edit this post to point to the latest stuff found on GitHub.

https://github.com/PaulMWatt/Alchemy

Regards,

Paul

Love the blog, found this entry most interesting. One of the things that drives me nuts is the assumptions about copy rights; to wit; on youtube is a copy of Robert Johnson’s classic “32-20 Blues", its a “tribute” type video with the audio overlaid with some deep south pictures and so on. The guy who put the video together mentions something about a copy right (I forget the attribution) even though the song passed into the public domain years ago. One should never make assertions about things they know NOTHING ABOUT!

Argh!

The download link is broken.

From where can I download the sources mentioned in this article.

-Ameya

Hello,

Thank you for the article.

In the “Does it have a name?” part, lvalue expressions that doesn’t have name were described as follows;

“Examples of lvalue expressions that do not have names are string literals and function call expressions that return an rvalue reference.”

Function call expressions that return a rvalue reference are xvalue, lvalue expressions must be function call expressions that return an lvalue, not rvalue.

No, it is not fixed.

It used to be a copy of the binary conversion with just the radix changed from 2 to 16.

Now you it reads:

237 / 16 224 D16 (13) (160)

224 / 16 13 E16 (14) (161)

You just put in the numbers from your (hex to dec) comment.

Thanks for clarifying, I understand what you were indicating.

It’s now corrected.

Thank you again.

Thanks for double-checking my work.

However, 0xED is the correct conversion for 237 from decimal to hexadecimal. A quick way to verify this is to convert 0xED back to decimal:

0xE(14) * 16 + 0xD(13) * 1 = 224 + 13 = 237

The quotient (answer to the division) is the value that we want to fill in the place-value spot during number conversion.

The remainder is what is left and carries over to the next lower place-value column.

The conversion of decimal 237 to hexadecimal is incorrect.

It should be:

237 / 16 = 14, remainder 13 -> 0xD

14 / 16 = 0, remainder 14 -> 0xE

Cross origin compile on coliru seems not working now, neither on en.cppreference.com nor here. It was working just a few days ago. I was trying to do the same thing with coliru, any idea ?

That is fascinating post and thank you for sharing. There are things here that I didn’t think some time recently. On account of cool such a position, to the point that is extremely elegantly composed. http://www.clazwork.com/proficient-accounting-essay-topics-writer

@Semi Essessi

Thanks for you input.

How do you deal with rotating a model and avoid matrix multiplication?

i have some strong opinions about this stuff having worked a lot out for myself from nothing… vectors, matrices and trig are overkill to start with, and introducing them so early obscures the simplicity of what is actually necessary imo…

as an obvious example, generic matrix multiplication is pretty useless (and classically confusing) compared to the change of basis/coordinate system that happens to be the same operation as multiplying square matrices.

This is probably the most thorough explanation I’ve seen on this subject. I found the tables and tips for navigating hexadecimal to be really helpful.

Thanks for pointing that out.

Yes, the code you mention is a mistake, I will correct it.

I adapted my implementation from the version in the proposal paper I cite, N4115. Their implementation chooses to swap the parameters. This form didn’t feel intuitive to me.

I needed the pop_back function, so the latest file I have uploaded has some additional functionality:

- pop_back

- move_item (moves items between lists)

- split (splits a list at a specified pivot point)

Is there a mistake on line 195( of the downloadable file), if not could you explain the template parameters are reversed (the line is also shown in your “One Last Tip” example above on line 20) ? Thanks

## Recent Comments