[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Calc: Multiply time (hours) with a float

From: Michael Welle
Subject: Re: [O] Calc: Multiply time (hours) with a float
Date: Mon, 19 Sep 2016 15:49:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)


Karl Voit <address@hidden> writes:

> * Michael Welle <address@hidden> wrote:
>> Karl Voit <address@hidden> writes:
>>>> [...]
>>>>> #+TBLFM: @2$3='(* $2 (org-time-string-to-hours "$1"));L
>>>> or converting $2 to a number before the calculation should work also,
>>>> but is more to write ;).
>>> Hm. I still got #ERROR. I reduced my issue to calculate the float (for 
>>> hours)
>>> without multiplying it with "value":
>> strange. I use the current Org version from git and Emacs 25.1.
>>> | time [h:m:s] |   value | product |
>>> |--------------+---------+---------|
>>> |     09:15:00 | 2.54321 | #ERROR  |
>>> #+TBLFM: @2$3='(org-time-string-to-hours $1)
>> That works for me. The default interpretation of $1 is used and
>> therefore the value is fed into o-t-s-t-h as string.
> OK, this is my current issue then.
The o-t-s-t-s function expect it to be a string, doesn't it? You test it
with (stringp s) there.

>>> #+TBLFM: @2$3='(org-time-string-to-hours "$1");N
>> Here you ask for interpretation as numbers. So the o-t-s-t-h function
>> sees a stringified 9 as it's parameter value. Near, but still no t-shirt ;). 
> I was wondering whether or not the stringification is done before or
> after the number-conversion - as a test. It's an #ERROR anyway.
The double quotes around $1 make it a string and your function parameter
named s is of type string. As I said, your function sees a "9" in this
variant and isn't prepared to work with that as input. That surely
results in an error.

>>> ... each of the TBLFM results in the same error.
>> Well, none of them looks like the one I wrote:
>> #+TBLFM: @2$3='(* $2 (org-time-string-to-hours "$1"));L
> ... which I tried first, got an #ERROR and analyzed the issue.
> Narrowing down to '(org-time-string-to-hours $1) is my issue since
> I now understand the handling of $2 which is according to the
> documentation.
>> You said, that gives an error, too. I have no idea, why. You can use
>> (message...) and (type-of ...) to look at the types and values that you
>> feed into your functions. Maybe that gives some insight?
> (type-of ...) -> very helpful
> | time [h:m:s] |   value | product |
> |--------------+---------+---------|
> |     09:15:00 | 2.54321 | #ERROR  |
> #+TBLFM: @2$3='(message (type-of (org-time-string-to-hours $1)))
> #+TBLFM: @2$3='(type-of (org-time-string-to-hours $1))
Try (message "type: %s" (type-of (org-time-string-to-hours $1)))

> ... both formulas lead to #ERROR in @2$3 with no message in the
> *Message* buffer.
> From my understanding, the first one should have caused an output of
> the type in the *Message* buffer and the second one should have
> placed something like "integer" into @2$3. Am I correct?
In the table above both formulas place the value of the evaluated form
in the product cell of the table. If you change the message example as
suggested above, the product cell will contain something like "type:
float", the second formula will insert just the type name: "float" in
that case. 

>> The variant with converting $2 to a number is:
>> #+TBLFM: @2$3='(* (string-to-number $2) (org-time-string-to-hours $1))
> Since the issue is with $1, the (string-to-number $2) (which is
> working) doesn't fix the #ERROR issue of $1 :-(
You can put

(message "type: '%s' value '%s'" (type-of s) s)

into your o-t-s-t-seconds function, right before the cond form. That
should print out a type of string and a value that can be processed by
the logic of that function, i.e. just "9" doesn't work, because of the
regexp you use as conditions.

> Thank you *very* much for your explanations! I (and hopefully many
> others as well) am learning a lot here.
What I find a bit strange is that things that work for me, doesn't work
in your environment. At first glance your function doesn't look so
special, IMO.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]