Re: balance assertions semantics
On 6/24/14 2:13 AM, Stefano Zacchiroli wrote: Several countries in the world uses comma as a digital separator. If not syntactically ambiguous---the subsequent space might save the day---using comma to separate assertions might get very hard on the eye for users that do use digital commas, e.g.: some:account $1 = EUR 10,20, CHF 3,2, $10,27 Yes, that's what the space is for; I haven't thought of anything better. ; is for comments, so can't use that. Double space ? -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rounding in ledger
Random notes: I feel rounding occurs or is used at these times: 1. when calculating a missing posting amount 2. when checking that postings balance 3. when converting from one commodity to another (due to -B/-V/-X or when balancing a mixed-commodity transaction) 4. when rendering an amount for output I'm thinking display precision could be set by, in order of precedence: 1. a command-line --precision flag (for simple overriding) 2. the precision declared for the commodity in the account, if displaying an account balance (not eg the final balance total) 3. the precision declared for the account, if displaying an account balance 4. the precision declared for the commodity 5. the maximum precision encountered for that commodity in posting amounts explicitly recorded in the journal (but not price amounts) And display precision can be: - -N digits (round to tens, hundreds or whatever) - 0 (no digits) - N digits - max (show all available precision) -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rounding in ledger
From reading the code exact arithmetic is used for 1-3 and rounding only occurs on display. On Tuesday, June 24, 2014, Simon Michael si...@joyful.com wrote: Random notes: I feel rounding occurs or is used at these times: 1. when calculating a missing posting amount 2. when checking that postings balance 3. when converting from one commodity to another (due to -B/-V/-X or when balancing a mixed-commodity transaction) 4. when rendering an amount for output I'm thinking display precision could be set by, in order of precedence: 1. a command-line --precision flag (for simple overriding) 2. the precision declared for the commodity in the account, if displaying an account balance (not eg the final balance total) 3. the precision declared for the account, if displaying an account balance 4. the precision declared for the commodity 5. the maximum precision encountered for that commodity in posting amounts explicitly recorded in the journal (but not price amounts) And display precision can be: - -N digits (round to tens, hundreds or whatever) - 0 (no digits) - N digits - max (show all available precision) -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Craig, Corona De Tucson, AZ enderw88.wordpress.com -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Building on FreeBSD 10.0
I'm having difficulties compiling the latest Ledger code on FreeBSD 10.0 (well, PC-BSD actually) with clang and Boost 1.55.0. I followed some suggested commands, step 2 from Thierry on 2014-05-04 in message a48ef73e-b08c-4e28-bfb9-69d1e1711...@googlegroups.com. I include the output below. If anyone has any suggestions for fixing this bug or compiling on FreeBSD I would be very happy to hear them. Until then, my ledgering is out of commission for a while. Thanks for any help, Chris --888-- cleyon@rosso:ledger-2014-06-24$ rm -rf ledger/ cleyon@rosso:ledger-2014-06-24$ git clone git://github.com/ledger/ledger.git Cloning into 'ledger'... remote: Reusing existing pack: 32431, done. remote: Total 32431 (delta 0), reused 0 (delta 0) Receiving objects: 100% (32431/32431), 14.13 MiB | 5.33 MiB/s, done. Resolving deltas: 100% (24322/24322), done. Checking connectivity... done. cleyon@rosso:ledger-2014-06-24$ cd ledger/ cleyon@rosso:ledger$ git submodule update --init Submodule 'lib/utfcpp' (http://github.com/ledger/utfcpp.git) registered for path 'lib/utfcpp' Cloning into 'lib/utfcpp'... remote: Reusing existing pack: 37, done. remote: Total 37 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (37/37), done. Checking connectivity... done. Submodule path 'lib/utfcpp': checked out '2233ec933f5661c7050b94d3b14f5f9f51ae3d55' cleyon@rosso:ledger$ cmake . -DUSE_DOXYGEN=1 -DUSE_PYTHON=1 -- The C compiler identification is Clang 3.3.0 -- The CXX compiler identification is Clang 3.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/CC -- Check for working CXX compiler: /usr/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PythonInterp: /usr/local/bin/python (found version 2.7.6) -- Found PythonLibs: /usr/local/lib/libpython2.7.so (found version 2.7.6) -- Boost version: 1.55.0 -- Found the following Boost libraries: -- date_time -- filesystem -- system -- iostreams -- regex -- unit_test_framework -- python -- Looking for access -- Looking for access - found -- Looking for realpath -- Looking for realpath - found -- Looking for getpwuid -- Looking for getpwuid - found -- Looking for getpwnam -- Looking for getpwnam - found -- Looking for isatty -- Looking for isatty - found -- Performing Test UNIX_PIPES_COMPILES -- Performing Test UNIX_PIPES_COMPILES - Success -- Performing Test BOOST_REGEX_UNICODE_RUNS -- Performing Test BOOST_REGEX_UNICODE_RUNS - Failed -- Looking for readline in edit -- Looking for readline in edit - found -- Found Doxygen: /usr/local/bin/doxygen (found version 1.8.3.1) -- Configuring done -- Generating done -- Build files have been written to: /usr/home/cleyon/tmp/ledger-2014-06-24/ledger cleyon@rosso:ledger$ make Scanning dependencies of target libledger [ 1%] Building CXX object src/CMakeFiles/libledger.dir/stats.cc.o [ 2%] Building CXX object src/CMakeFiles/libledger.dir/generate.cc.o [ 4%] Building CXX object src/CMakeFiles/libledger.dir/csv.cc.o [ 5%] Building CXX object src/CMakeFiles/libledger.dir/convert.cc.o [ 6%] Building CXX object src/CMakeFiles/libledger.dir/draft.cc.o [ 8%] Building CXX object src/CMakeFiles/libledger.dir/emacs.cc.o [ 9%] Building CXX object src/CMakeFiles/libledger.dir/org.cc.o [ 10%] Building CXX object src/CMakeFiles/libledger.dir/ptree.cc.o [ 12%] Building CXX object src/CMakeFiles/libledger.dir/print.cc.o [ 13%] Building CXX object src/CMakeFiles/libledger.dir/output.cc.o /usr/home/cleyon/tmp/ledger-2014-06-24/ledger/src/output.cc:294:48: error: no viable conversion from '__map_iterator__tree_iteratorunion std::__1::mapclass ledger::account_t *, unsigned long, struct ledger::account_compare, class std::__1::allocatorstruct std::__1::pairclass ledger::account_t *const, unsigned long ::__value_type, class std::__1::__tree_nodeunion std::__1::mapclass ledger::account_t *, unsigned long, struct ledger::account_compare, class std::__1::allocatorstruct std::__1::pairclass ledger::account_t *const, unsigned long ::__value_type, void * *, [...]' to '__map_iterator__tree_iteratorunion std::__1::mapclass ledger::account_t *, unsigned long, struct std::__1::lessclass ledger::account_t *, class std::__1::allocatorstruct std::__1::pairclass ledger::account_t *const, unsigned long ::__value_type, class std::__1::__tree_nodeunion std::__1::mapclass ledger::account_t *, unsigned long, struct std::__1::lessclass ledger::account_t *, class std::__1::allocatorstruct std::__1::pairclass ledger::account_t *const, unsigned long ::__value_type, void * *, [...]' std::mapaccount_t *, std::size_t::iterator i = accounts.find(post.account); ^ ~~~
Re: Building on FreeBSD 10.0
On 24.06.14,14:30, Chris Leyon wrote: I'm having difficulties compiling the latest Ledger code on FreeBSD 10.0 (well, PC-BSD actually) with clang and Boost 1.55.0. I followed some suggested commands, step 2 from Thierry on 2014-05-04 in message a48ef73e-b08c-4e28-bfb9-69d1e1711...@googlegroups.com. I include the output below. If anyone has any suggestions for fixing this bug or compiling on FreeBSD I would be very happy to hear them. Until then, my ledgering is out of commission for a while. Thanks for any help, Chris --888-- cleyon@rosso:ledger-2014-06-24$ rm -rf ledger/ cleyon@rosso:ledger-2014-06-24$ git clone git://github.com/ledger/ledger.git Cloning into 'ledger'... remote: Reusing existing pack: 32431, done. remote: Total 32431 (delta 0), reused 0 (delta 0) Receiving objects: 100% (32431/32431), 14.13 MiB | 5.33 MiB/s, done. Resolving deltas: 100% (24322/24322), done. Checking connectivity... done. cleyon@rosso:ledger-2014-06-24$ cd ledger/ cleyon@rosso:ledger$ git submodule update --init Submodule 'lib/utfcpp' (http://github.com/ledger/utfcpp.git) ... The most recent version of ledger do work with boost versions from 1.49 and up. You can try this: Delete the ledger directory and clone it again. Go into the CMakeLists.txt file and change this line: add_definitions(-std=c++11) to: add_definitions(-std=c++11 -U__STRICT_ANSI__) Then run: ./acprep --python update and see if that works. Jostein -- --- You received this message because you are subscribed to the Google Groups Ledger group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to record and keep track of stock share ?
Allowing the cost to show up in both places would break the accounting equation; this transaction must balance. So I've been thinking about this and I think that is the fundamental problem. Technically, commission (at least in the U.S.) isn't an expense, it's an asset. It sounds strange, but think about it. In the U.S., the commission counts toward the cost basis and the cost basis is recorded with the asset. It's the whole depreciate vs. expense issue in accounting. I'm not sure how, but I think the solution is somewhere down that road. Maybe creating a fake asset that is the commission per share, maybe a sub-asset. The thing is, this isn't a new problem. This isn't a ledger problem so much as an accounting problem. Accountants (in the U.S. at least) already have to deal with this situation. Does anyone know how accountants deal with this currently? Rick On Saturday, June 14, 2014 10:50:32 AM UTC-7, Martin Blais wrote: On Fri, Jun 13, 2014 at 9:57 AM, Martin Blais bl...@furius.ca javascript: wrote: On Fri, Jun 13, 2014 at 9:01 AM, Rick F ri...@farnbach.com javascript: wrote: The method used in the cookbook, is not correct. That's not exactly true: it's correct if your definition of capital gain does not take into account commissions. I used the definition that excludes capital gains in order to keep things simple (the level of discussion I chose in that doc is that congruent with trying to explain P/L clearly, intro level). Whether you should be able to exclude commissions or not from your gains is a matter tax law, and it depends on your own situation. Thanks for bringing up the topic, though, I admit I did forget to explain it. I'll add a separate section about commissions. I'm well aware of this. At the moment, I simply subtract the commissions from the gains for reporting. The gains and commissions get counted in separate accounts (which is mostly fine, except for the prorating detail you bring up below). You can subtract the total commissions from total gain for a good approximation of gains-without-commissions. Most of my trading accounts already provide a suitable 1099 so I use my own accounting on these accounts for tax planning and cross-checking against their calculations, and I use the 1099 forms for tax reporting. The cookbook uses the example of buying 10 shares of IBM at $160 and then selling those shares at $170. Without commissions, that would amount to a realized gain of $100, $1700 (the sales price) - $1600 (the cost basis). With commissions, however, the reportable gain is really $1700 (the sales price) - $9.95 (commission on the sale) - $1600 (basis) - $9.95 (commission on purchase) = $80.10. The method in the cookbook only accounts for the sale commission when figuring the capital gain. Actually, that's incorrect, the method I described does exclude the commission from the gain on BOTH sides and will thus calculate a gain of 100$ (no commissions at all). So what's the right way to do this, accounting for commission on purchase. Note that if only part of the purchased shares are sold the commission is prorated, so the actual basis is $1609.95 or $160.995 per share. That's a great question. Again, how it should be done is a matter of tax law, it's a choice, but this is indeed a sensible one in many cases. Simply subtracting the sum of the commissions - you could easily track them per account, e.g. using Expenses:US:ETrade:Commissions instead of Expenses:Financial:Commissions - from the capital gains provides a good approximation of the gains as you describe it, but as you point out, not a perfectly accurate one, especially if you hold positions across reporting periods (taxation years). It is appropriate to note that folding in the purchase commission on the cost basis is but one method to automatically pro-rate that commission into the gain - we could track it separately, per-lot - but it is one that is elegant and leads to an unambiguous implementation. I would like to be able to support it. I don't have a good solution for doing this at the moment, but I want to think of one. In particular, we should design a method that leads to easy entry by a user, with a correspondingly nice syntax. I'll be thinking about this; any ideas welcome. Some more thinking about this: one possible method would be to allow the user to indicate that a particular leg of the transaction is meant to be folded into the cost of another leg's, something I would implement like the following. First let's make up an example of a transaction the way they're currently done, with the full capital gain, that is, one that unfairly (to you) includes commissions: 2014-06-13 * Transactions with Commissions Assets:US:Invest:Cash-5009.95 USD ; 5009.95 USD Expenses:US:Invest:Commissions 9.95 USD ;
