Turn the following values into percentage [closed]












4












$begingroup$


I have the following data:
{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}
{5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}
My data is already in Matrix form in Mathematica, is there a possibility to change the second raw into percentages? I want the first data: 5914 to be 100% and calculate how much did the data grow over the years based on the first year. So the last number should be: 324%.
How could this be done automatically and for a huge set of data?
Thank you!






list-manipulation numerics







share|improve this question











$endgroup$



closed as off-topic by Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey Jan 6 at 1:03


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "This question arises due to a simple mistake such as a trivial syntax error, incorrect capitalization, spelling mistake, or other typographical error and is unlikely to help any future visitors, or else it is easily found in the documentation." – Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey

If this question can be reworded to fit the rules in the help center, please edit the question.
















  • $begingroup$
    try this data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}; secondData = data[[2]]; secondData = IntegerPart[N[#*100/First[secondData]]]& /@ secondData; data[[2]] = secondData;
    $endgroup$
    – Xminer
    Jan 4 at 14:13








  • 1




    $begingroup$
    Just divide your array with the first element? arr/First[arr]. You might want to go through some basic tutorials: wolfram.com/language/elementary-introduction/2nd-ed
    $endgroup$
    – Szabolcs
    Jan 4 at 14:14
















4












$begingroup$


I have the following data:
{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}
{5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}
My data is already in Matrix form in Mathematica, is there a possibility to change the second raw into percentages? I want the first data: 5914 to be 100% and calculate how much did the data grow over the years based on the first year. So the last number should be: 324%.
How could this be done automatically and for a huge set of data?
Thank you!






list-manipulation numerics







share|improve this question











$endgroup$



closed as off-topic by Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey Jan 6 at 1:03


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "This question arises due to a simple mistake such as a trivial syntax error, incorrect capitalization, spelling mistake, or other typographical error and is unlikely to help any future visitors, or else it is easily found in the documentation." – Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey

If this question can be reworded to fit the rules in the help center, please edit the question.
















  • $begingroup$
    try this data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}; secondData = data[[2]]; secondData = IntegerPart[N[#*100/First[secondData]]]& /@ secondData; data[[2]] = secondData;
    $endgroup$
    – Xminer
    Jan 4 at 14:13








  • 1




    $begingroup$
    Just divide your array with the first element? arr/First[arr]. You might want to go through some basic tutorials: wolfram.com/language/elementary-introduction/2nd-ed
    $endgroup$
    – Szabolcs
    Jan 4 at 14:14














4












4








4





$begingroup$


I have the following data:
{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}
{5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}
My data is already in Matrix form in Mathematica, is there a possibility to change the second raw into percentages? I want the first data: 5914 to be 100% and calculate how much did the data grow over the years based on the first year. So the last number should be: 324%.
How could this be done automatically and for a huge set of data?
Thank you!






list-manipulation numerics







share|improve this question











$endgroup$




I have the following data:
{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}
{5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}
My data is already in Matrix form in Mathematica, is there a possibility to change the second raw into percentages? I want the first data: 5914 to be 100% and calculate how much did the data grow over the years based on the first year. So the last number should be: 324%.
How could this be done automatically and for a huge set of data?
Thank you!






list-manipulation numerics




list-manipulation numerics






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 5 at 14:52









J. M. is slightly pensive♦

97.9k10304464




97.9k10304464










asked Jan 4 at 14:06









user62202user62202

241




241




closed as off-topic by Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey Jan 6 at 1:03


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "This question arises due to a simple mistake such as a trivial syntax error, incorrect capitalization, spelling mistake, or other typographical error and is unlikely to help any future visitors, or else it is easily found in the documentation." – Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey

If this question can be reworded to fit the rules in the help center, please edit the question.







closed as off-topic by Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey Jan 6 at 1:03


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "This question arises due to a simple mistake such as a trivial syntax error, incorrect capitalization, spelling mistake, or other typographical error and is unlikely to help any future visitors, or else it is easily found in the documentation." – Szabolcs, Thies Heidecke, Bob Hanlon, m_goldberg, bbgodfrey

If this question can be reworded to fit the rules in the help center, please edit the question.












  • $begingroup$
    try this data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}; secondData = data[[2]]; secondData = IntegerPart[N[#*100/First[secondData]]]& /@ secondData; data[[2]] = secondData;
    $endgroup$
    – Xminer
    Jan 4 at 14:13








  • 1




    $begingroup$
    Just divide your array with the first element? arr/First[arr]. You might want to go through some basic tutorials: wolfram.com/language/elementary-introduction/2nd-ed
    $endgroup$
    – Szabolcs
    Jan 4 at 14:14


















  • $begingroup$
    try this data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}; secondData = data[[2]]; secondData = IntegerPart[N[#*100/First[secondData]]]& /@ secondData; data[[2]] = secondData;
    $endgroup$
    – Xminer
    Jan 4 at 14:13








  • 1




    $begingroup$
    Just divide your array with the first element? arr/First[arr]. You might want to go through some basic tutorials: wolfram.com/language/elementary-introduction/2nd-ed
    $endgroup$
    – Szabolcs
    Jan 4 at 14:14
















$begingroup$
try this data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}; secondData = data[[2]]; secondData = IntegerPart[N[#*100/First[secondData]]]& /@ secondData; data[[2]] = secondData;
$endgroup$
– Xminer
Jan 4 at 14:13






$begingroup$
try this data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}; secondData = data[[2]]; secondData = IntegerPart[N[#*100/First[secondData]]]& /@ secondData; data[[2]] = secondData;
$endgroup$
– Xminer
Jan 4 at 14:13






1




1




$begingroup$
Just divide your array with the first element? arr/First[arr]. You might want to go through some basic tutorials: wolfram.com/language/elementary-introduction/2nd-ed
$endgroup$
– Szabolcs
Jan 4 at 14:14




$begingroup$
Just divide your array with the first element? arr/First[arr]. You might want to go through some basic tutorials: wolfram.com/language/elementary-introduction/2nd-ed
$endgroup$
– Szabolcs
Jan 4 at 14:14










3 Answers
3






active

oldest

votes


















7












$begingroup$

(I get to show this first...)



data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 

    2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 

    18800, 19216}};

{data[[1]], PercentForm[N[data[[2]]]/data[[2, 1]]]}


enter image description here



(...coming soon, in version 12)






share|improve this answer









$endgroup$









  • 3




    $begingroup$
    @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
    $endgroup$
    – Daniel Lichtblau
    Jan 4 at 17:17






  • 1




    $begingroup$
    Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
    $endgroup$
    – Rolf Mertig
    Jan 4 at 21:59






  • 1




    $begingroup$
    @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
    $endgroup$
    – Daniel Lichtblau
    Jan 4 at 23:04






  • 1




    $begingroup$
    @ΑλέξανδροςΖεγγ Did you run the code I posted?
    $endgroup$
    – Daniel Lichtblau
    Jan 5 at 16:04






  • 1




    $begingroup$
    Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
    $endgroup$
    – Szabolcs
    Jan 7 at 11:38



















5












$begingroup$

data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143,6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}


There's no need to define additional variables,try



data[[2]] = 100 data[[2]]/data[[2, 1]]//Round[#,1]& (*//IntegerPart*)  ;

data

(*{{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, 

{100,103, 104, 304, 307, 310, 312, 312, 317, 324}}*)





share|improve this answer











$endgroup$













  • $begingroup$
    In many applications, Round would be more appropriate than IntegerPart
    $endgroup$
    – Bob Hanlon
    Jan 4 at 14:35










  • $begingroup$
    @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
    $endgroup$
    – Ulrich Neumann
    Jan 4 at 14:45












  • $begingroup$
    @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
    $endgroup$
    – Henrik Schumacher
    Jan 4 at 15:01










  • $begingroup$
    @ Henrik Thanks, my actual answer seems to be the power-version!
    $endgroup$
    – Ulrich Neumann
    Jan 4 at 16:19



















1












$begingroup$

Similar to the above:



k = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 

   2017} , {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 

   18800, 19216}}



k[[2]]=Flatten[Floor[100*Rest[k]/Flatten[Rest[k]][[1]]]]


Gives



{{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017},
{100, 103, 104, 304, 307, 310, 312, 312, 317, 324}}






share|improve this answer









$endgroup$




















    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    7












    $begingroup$

    (I get to show this first...)



    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
    
    2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
    
    18800, 19216}};
    
{data[[1]], PercentForm[N[data[[2]]]/data[[2, 1]]]}


    enter image description here



    (...coming soon, in version 12)






    share|improve this answer









    $endgroup$









    • 3




      $begingroup$
      @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 17:17






    • 1




      $begingroup$
      Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
      $endgroup$
      – Rolf Mertig
      Jan 4 at 21:59






    • 1




      $begingroup$
      @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 23:04






    • 1




      $begingroup$
      @ΑλέξανδροςΖεγγ Did you run the code I posted?
      $endgroup$
      – Daniel Lichtblau
      Jan 5 at 16:04






    • 1




      $begingroup$
      Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
      $endgroup$
      – Szabolcs
      Jan 7 at 11:38
















    7












    $begingroup$

    (I get to show this first...)



    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
    
    2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
    
    18800, 19216}};
    
{data[[1]], PercentForm[N[data[[2]]]/data[[2, 1]]]}


    enter image description here



    (...coming soon, in version 12)






    share|improve this answer









    $endgroup$









    • 3




      $begingroup$
      @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 17:17






    • 1




      $begingroup$
      Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
      $endgroup$
      – Rolf Mertig
      Jan 4 at 21:59






    • 1




      $begingroup$
      @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 23:04






    • 1




      $begingroup$
      @ΑλέξανδροςΖεγγ Did you run the code I posted?
      $endgroup$
      – Daniel Lichtblau
      Jan 5 at 16:04






    • 1




      $begingroup$
      Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
      $endgroup$
      – Szabolcs
      Jan 7 at 11:38














    7












    7








    7





    $begingroup$

    (I get to show this first...)



    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
    
    2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
    
    18800, 19216}};
    
{data[[1]], PercentForm[N[data[[2]]]/data[[2, 1]]]}


    enter image description here



    (...coming soon, in version 12)






    share|improve this answer









    $endgroup$



    (I get to show this first...)



    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
    
    2017}, {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
    
    18800, 19216}};
    
{data[[1]], PercentForm[N[data[[2]]]/data[[2, 1]]]}


    enter image description here



    (...coming soon, in version 12)







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jan 4 at 16:16









    Daniel LichtblauDaniel Lichtblau

    47.2k276164




    47.2k276164








    • 3




      $begingroup$
      @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 17:17






    • 1




      $begingroup$
      Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
      $endgroup$
      – Rolf Mertig
      Jan 4 at 21:59






    • 1




      $begingroup$
      @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 23:04






    • 1




      $begingroup$
      @ΑλέξανδροςΖεγγ Did you run the code I posted?
      $endgroup$
      – Daniel Lichtblau
      Jan 5 at 16:04






    • 1




      $begingroup$
      Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
      $endgroup$
      – Szabolcs
      Jan 7 at 11:38














    • 3




      $begingroup$
      @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 17:17






    • 1




      $begingroup$
      Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
      $endgroup$
      – Rolf Mertig
      Jan 4 at 21:59






    • 1




      $begingroup$
      @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
      $endgroup$
      – Daniel Lichtblau
      Jan 4 at 23:04






    • 1




      $begingroup$
      @ΑλέξανδροςΖεγγ Did you run the code I posted?
      $endgroup$
      – Daniel Lichtblau
      Jan 5 at 16:04






    • 1




      $begingroup$
      Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
      $endgroup$
      – Szabolcs
      Jan 7 at 11:38








    3




    3




    $begingroup$
    @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
    $endgroup$
    – Daniel Lichtblau
    Jan 4 at 17:17




    $begingroup$
    @RolfMertig The decimal point disparity was a design choice (at the insistence of the boss), to only put in a decimal when the value does not coerce to an integer. As for using N, we opted not to coerce exact values, other than integers, into percentages. So that was also a design choice.
    $endgroup$
    – Daniel Lichtblau
    Jan 4 at 17:17




    1




    1




    $begingroup$
    Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
    $endgroup$
    – Rolf Mertig
    Jan 4 at 21:59




    $begingroup$
    Greetings to the boss: wrong design choice. It was always a pain to construct nicely aligned and consisent tables of real numbers. And what is even worse is that the documentation does not fit the behaviour of Mathematica anymore (at least in such type of details).I do remeber a time when the documentation coincided with the software (which was one reason I switched from Macsyma to Mathematica ...).
    $endgroup$
    – Rolf Mertig
    Jan 4 at 21:59




    1




    1




    $begingroup$
    @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
    $endgroup$
    – Daniel Lichtblau
    Jan 4 at 23:04




    $begingroup$
    @RolfMertig I agree the alignment of numbers is not always easy. But I don't see what exact fractions have to do with formatting reals. On the topic of formatting reals, DecimalForm has seen some fixes..
    $endgroup$
    – Daniel Lichtblau
    Jan 4 at 23:04




    1




    1




    $begingroup$
    @ΑλέξανδροςΖεγγ Did you run the code I posted?
    $endgroup$
    – Daniel Lichtblau
    Jan 5 at 16:04




    $begingroup$
    @ΑλέξανδροςΖεγγ Did you run the code I posted?
    $endgroup$
    – Daniel Lichtblau
    Jan 5 at 16:04




    1




    1




    $begingroup$
    Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
    $endgroup$
    – Szabolcs
    Jan 7 at 11:38




    $begingroup$
    Is there already a timeline for v12.0? If you have any say in this, please just make sure there's a release candidate sent to testers before a 12.0 final suddenly appears ...
    $endgroup$
    – Szabolcs
    Jan 7 at 11:38











    5












    $begingroup$

    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143,6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}


    There's no need to define additional variables,try



    data[[2]] = 100 data[[2]]/data[[2, 1]]//Round[#,1]& (*//IntegerPart*)  ;
    
data
    
(*{{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, 
    
{100,103, 104, 304, 307, 310, 312, 312, 317, 324}}*)





    share|improve this answer











    $endgroup$













    • $begingroup$
      In many applications, Round would be more appropriate than IntegerPart
      $endgroup$
      – Bob Hanlon
      Jan 4 at 14:35










    • $begingroup$
      @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 14:45












    • $begingroup$
      @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
      $endgroup$
      – Henrik Schumacher
      Jan 4 at 15:01










    • $begingroup$
      @ Henrik Thanks, my actual answer seems to be the power-version!
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 16:19
















    5












    $begingroup$

    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143,6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}


    There's no need to define additional variables,try



    data[[2]] = 100 data[[2]]/data[[2, 1]]//Round[#,1]& (*//IntegerPart*)  ;
    
data
    
(*{{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, 
    
{100,103, 104, 304, 307, 310, 312, 312, 317, 324}}*)





    share|improve this answer











    $endgroup$













    • $begingroup$
      In many applications, Round would be more appropriate than IntegerPart
      $endgroup$
      – Bob Hanlon
      Jan 4 at 14:35










    • $begingroup$
      @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 14:45












    • $begingroup$
      @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
      $endgroup$
      – Henrik Schumacher
      Jan 4 at 15:01










    • $begingroup$
      @ Henrik Thanks, my actual answer seems to be the power-version!
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 16:19














    5












    5








    5





    $begingroup$

    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143,6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}


    There's no need to define additional variables,try



    data[[2]] = 100 data[[2]]/data[[2, 1]]//Round[#,1]& (*//IntegerPart*)  ;
    
data
    
(*{{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, 
    
{100,103, 104, 304, 307, 310, 312, 312, 317, 324}}*)





    share|improve this answer











    $endgroup$



    data = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, {5914, 6143,6182, 18000, 18173, 18344, 18454, 18506, 18800, 19216}}


    There's no need to define additional variables,try



    data[[2]] = 100 data[[2]]/data[[2, 1]]//Round[#,1]& (*//IntegerPart*)  ;
    
data
    
(*{{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017}, 
    
{100,103, 104, 304, 307, 310, 312, 312, 317, 324}}*)






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 4 at 14:46

























    answered Jan 4 at 14:26









    Ulrich NeumannUlrich Neumann

    9,548617




    9,548617












    • $begingroup$
      In many applications, Round would be more appropriate than IntegerPart
      $endgroup$
      – Bob Hanlon
      Jan 4 at 14:35










    • $begingroup$
      @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 14:45












    • $begingroup$
      @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
      $endgroup$
      – Henrik Schumacher
      Jan 4 at 15:01










    • $begingroup$
      @ Henrik Thanks, my actual answer seems to be the power-version!
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 16:19


















    • $begingroup$
      In many applications, Round would be more appropriate than IntegerPart
      $endgroup$
      – Bob Hanlon
      Jan 4 at 14:35










    • $begingroup$
      @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 14:45












    • $begingroup$
      @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
      $endgroup$
      – Henrik Schumacher
      Jan 4 at 15:01










    • $begingroup$
      @ Henrik Thanks, my actual answer seems to be the power-version!
      $endgroup$
      – Ulrich Neumann
      Jan 4 at 16:19
















    $begingroup$
    In many applications, Round would be more appropriate than IntegerPart
    $endgroup$
    – Bob Hanlon
    Jan 4 at 14:35




    $begingroup$
    In many applications, Round would be more appropriate than IntegerPart
    $endgroup$
    – Bob Hanlon
    Jan 4 at 14:35












    $begingroup$
    @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
    $endgroup$
    – Ulrich Neumann
    Jan 4 at 14:45






    $begingroup$
    @ Bob Hanlon Thanks, you're right (but it is a liitle bit slower ;-) )
    $endgroup$
    – Ulrich Neumann
    Jan 4 at 14:45














    $begingroup$
    @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
    $endgroup$
    – Henrik Schumacher
    Jan 4 at 15:01




    $begingroup$
    @Ulrich If it is about speed, I'd prefer data[[2]] = Round[data[[2]] (100. /data[[2, 1]]), 1]. The converts to machine precision numbers and reduces the number of scalar-vector multiplications from 2 to 1.
    $endgroup$
    – Henrik Schumacher
    Jan 4 at 15:01












    $begingroup$
    @ Henrik Thanks, my actual answer seems to be the power-version!
    $endgroup$
    – Ulrich Neumann
    Jan 4 at 16:19




    $begingroup$
    @ Henrik Thanks, my actual answer seems to be the power-version!
    $endgroup$
    – Ulrich Neumann
    Jan 4 at 16:19











    1












    $begingroup$

    Similar to the above:



    k = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
    
   2017} , {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
    
   18800, 19216}}
    

    
k[[2]]=Flatten[Floor[100*Rest[k]/Flatten[Rest[k]][[1]]]]


    Gives



    {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017},
    {100, 103, 104, 304, 307, 310, 312, 312, 317, 324}}






    share|improve this answer









    $endgroup$


















      1












      $begingroup$

      Similar to the above:



      k = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
      
   2017} , {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
      
   18800, 19216}}
      

      
k[[2]]=Flatten[Floor[100*Rest[k]/Flatten[Rest[k]][[1]]]]


      Gives



      {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017},
      {100, 103, 104, 304, 307, 310, 312, 312, 317, 324}}






      share|improve this answer









      $endgroup$
















        1












        1








        1





        $begingroup$

        Similar to the above:



        k = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
        
   2017} , {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
        
   18800, 19216}}
        

        
k[[2]]=Flatten[Floor[100*Rest[k]/Flatten[Rest[k]][[1]]]]


        Gives



        {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017},
        {100, 103, 104, 304, 307, 310, 312, 312, 317, 324}}






        share|improve this answer









        $endgroup$



        Similar to the above:



        k = {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 
        
   2017} , {5914, 6143, 6182, 18000, 18173, 18344, 18454, 18506, 
        
   18800, 19216}}
        

        
k[[2]]=Flatten[Floor[100*Rest[k]/Flatten[Rest[k]][[1]]]]


        Gives



        {{2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017},
        {100, 103, 104, 304, 307, 310, 312, 312, 317, 324}}







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 4 at 15:20









        GerardF123GerardF123

        1547




        1547















            -

            Popular posts from this blog

            Bressuire

            Image
            .mw-parser-output .infobox{border:1px solid #aaa;background-color:#f9f9f9;color:black;margin:.5em 0 .5em 1em;padding:.2em;float:right;clear:right;width:22em;text-align:left;font-size:88%;line-height:1.6em}.mw-parser-output .infobox td,.mw-parser-output .infobox th{vertical-align:top;padding:0 .2em}.mw-parser-output .infobox caption{font-size:larger}.mw-parser-output .infobox.bordered{border-collapse:collapse}.mw-parser-output .infobox.bordered td,.mw-parser-output .infobox.bordered th{border:1px solid #aaa}.mw-parser-output .infobox.bordered .borderless td,.mw-parser-output .infobox.bordered .borderless th{border:0}.mw-parser-output .infobox-showbutton .mw-collapsible-text{color:inherit}.mw-parser-output .infobox.bordered .mergedtoprow td,.mw-parser-output .infobox.bordered .mergedtoprow th{border:0;border-top:1px solid #aaa;border-right:1px solid #aaa}.mw-parser-output .infobox.bordered .mergedrow td,.mw-parser-output .infobox.bordered .mergedrow th{border:0;border-right:1px solid ...
            Read more

            Cabo Verde

            Image
              Nota: Cabo-verdiano redireciona para este artigo. Para a língua falada em Cabo Verde, veja crioulo cabo-verdiano. Para outros significados, veja Cabo Verde (desambiguação). Coordenadas: 14° 55' N 23° 31' O Cabo Verde República de Cabo Verde Bandeira Brasão de Armas Lema: Unidade, Trabalho, Progresso Hino nacional: Cântico da Liberdade Gentílico: cabo-verdiano [ 1 ] Capital Praia 14° 55' N 23° 31' O Cidade mais populosa Praia Língua oficial Português Governo República unitária semipresidencialista [ 2 ]  - Presidente Jorge Carlos Fonseca  - Primeiro-ministro Ulisses Correia e Silva História    - Descoberta 1460   - Independência 00 • de Portugal 5 de Julho de 1975   - Multipartidarismo 13 de Janeiro de 1990  Área    - Total 4 033 km² (146.º)  - Água (%) 0,08 População    - Estimativa para 2017 560 899 [ 3 ] hab. (173.º) ...
            Read more

            Gyllenstierna

            Image
            .mw-parser-output .infobox{border:1px solid #aaa;background-color:#f9f9f9;color:black;margin:.5em 0 .5em 1em;padding:.2em;float:right;clear:right;width:22em;text-align:left;font-size:88%;line-height:1.6em}.mw-parser-output .infobox td,.mw-parser-output .infobox th{vertical-align:top;padding:0 .2em}.mw-parser-output .infobox caption{font-size:larger}.mw-parser-output .infobox.bordered{border-collapse:collapse}.mw-parser-output .infobox.bordered td,.mw-parser-output .infobox.bordered th{border:1px solid #aaa}.mw-parser-output .infobox.bordered .borderless td,.mw-parser-output .infobox.bordered .borderless th{border:0}.mw-parser-output .infobox-showbutton .mw-collapsible-text{color:inherit}.mw-parser-output .infobox.bordered .mergedtoprow td,.mw-parser-output .infobox.bordered .mergedtoprow th{border:0;border-top:1px solid #aaa;border-right:1px solid #aaa}.mw-parser-output .infobox.bordered .mergedrow td,.mw-parser-output .infobox.bordered .mergedrow th{border:0;border-right:1px solid ...
            Read more